# vscode-elixir-ls: VS Code support that runs your project to understand it

> This extension gives VS Code an Elixir language server and debug adapter on top of ElixirLS, and the interesting part is that it does not parse Elixir statically. It compiles your project, runs Mix tasks and analyses the result, which is why the extension declares untrusted workspaces unsupported and requires a real filesystem.

**elixir-lsp/vscode-elixir-ls** — Elixir language support and debugger for VS Code, powered by ElixirLS.

- Repository: https://github.com/elixir-lsp/vscode-elixir-ls
- Website: https://marketplace.visualstudio.com/items?itemName=JakeBecker.elixir-ls
- Stars: 599 · Forks: 109
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/elixir-lsp-vscode-elixir-ls

## The extension is a thin shell over ElixirLS

The README is direct about the division of labour. This extension provides the Elixir language server and debug adapter, and it is powered by the Elixir Language Server, ElixirLS, which is an Elixir implementation of Microsoft's IDE-agnostic Language Server Protocol and Debug Adapter Protocol. The extension itself is written in TypeScript, with the main entry point at ./out/extension.js and the sources in src/, and it is packaged as elixir-ls with the display name ElixirLS: Elixir support and debugger, published by JakeBecker, version 0.31.1, and requiring VS Code engine ^1.105.0. The licence is MIT, and the marketplace listing is the one the README links for installation.

The feature list is long enough to be worth reading rather than skimming. There is code completion, debugger support, test discovery and running through the Test Explorer, automatic incremental Dialyzer analysis, automatic suggestion for @spec annotations based on Dialyzer's inferred success typings, diagnostic reporting of build warnings and errors, go-to-definition and go-to-implementation, a task provider collecting mix tasks, smart automatic closing of code blocks, documentation lookup on hover, a function signature provider, a code formatter triggered by the Alt + Shift + F hotkey or by enabling editor.formatOnSave, find references to functions and modules, document and workspace symbols, and multi-root workspaces. The categories in the package manifest say the same thing in four words: Programming Languages, Debuggers, Linters, Testing and Formatters.

## A fork taken over after the original went quiet

The governance story is in the README and it explains why the extension behaves the way it does. The elixir-lsp organisation's vscode-elixir-ls repository began as a fork when the original repository at JakeBecker/vscode-elixir-ls became inactive for an extended period of time, and the stated reason for starting an active fork was to merge dormant pull requests and fix issues where possible. The README also says the team believes in an open and shared governance model to share the work instead of relying on one person to shoulder the whole burden. The original repository has now been deprecated in favor of this one, and future updates to the original VS Code ElixirLS extension will come from this repository.

The publisher field in the manifest still says JakeBecker, and the marketplace listing URL in the README is the one under that name, so the distribution channel kept the old identity while the code moved. For a user, the practical effect is that the extension they already have from the marketplace is the one that gets the fixes, and the repository they might visit for issues is the elixir-lsp one. The last push to the repository was on 2026-10-18, and the project publishes no GitHub releases, so the changelog in CHANGELOG.md is the version history.

## Opinionated defaults that match the Elixir formatter

ElixirLS sets defaults for Elixir files, and the README calls it opinionated. The block below is the whole default set, and the comments in it are the interesting part.

```jsonc
{
  // Based on Elixir formatter's style
  "editor.insertSpaces": true,
  // Note: While it is possible to override this in your VSCode configuration, the Elixir Formatter
  // does not support a configurable tab size, so if you override this then you should not use the
  // formatter.
  "editor.tabSize": 2,
  "files.trimTrailingWhitespace": true,
  "files.insertFinalNewline": true,
  "files.trimFinalNewlines": true,

  // Provides smart completion for "do" and "fn ->" blocks. Does not run the Elixir formatter.
  "editor.formatOnType": true,

  // Misc
  "editor.wordBasedSuggestions": "off",
  "editor.trimAutoWhitespace": false,
  "editor.snippetSuggestions": "inline"
}
```

Two of these defaults interact. formatOnType is on, which the comment says provides smart completion for do and fn -> blocks and does not run the Elixir formatter, and tabSize is fixed at 2 because the formatter does not support a configurable tab size. The README points out the consequence directly: if you override the tab size, you should not use the formatter. You can change any of it in your user settings or per project in .vscode/settings.json, which is where the next section's launch configuration lives too.

## The test runner builds a launch configuration on the fly

Running and debugging tests goes through a launch configuration that the extension generates rather than one you write. The type is mix_task, the name is mix test, and the environment sets MIX_ENV to test, with the task arguments computed by buildTestCommandArgs(args, debug).

```js
{
  "type": "mix_task",
  "name": "mix test",
  "request": "launch",
  "task": "test",
  "env": {
    "MIX_ENV": "test",
  },
  "taskArgs": buildTestCommandArgs(args, debug),
  "startApps": true,
  "projectDir": args.cwd,
  // we need to require all test helpers and only the file we need to test
  // mix test runs tests in all required files even if they do not match
  // given path:line
  "requireFiles": [
    "test/**/test_helper.exs",
    "apps/*/test/**/test_helper.exs",
    args.filePath,
  ],
  "noDebug": !debug,
}
```

The requireFiles list is the interesting part, and the comment explains why: mix test runs tests in all required files even when they do not match the given path or line, so the configuration requires every test helper plus only the file under test. You can override the whole thing by providing a project launch configuration named mix test, in which case that one is used as the default for running and debugging tests.

```json
{
  "type": "mix_task",
  "name": "mix test",
  "request": "launch",
  "debugAutoInterpretAllModules": false,
  "debugInterpretModulesPatterns": ["MyApp*"]
}
```

## The extension will not run in a workspace you do not trust

This is the part to read before installing. The package manifest declares untrustedWorkspaces as not supported, and the description explains why: ElixirLS compiles the project and runs Mix tasks, which executes code from the project and all of its dependencies, including compile-time code such as macros, mix.exs and dependency build scripts. The advice is to only trust workspaces whose project and dependency sources you trust.

Virtual workspaces are also declared unsupported, with the reason that ElixirLS requires access to Mix and the project files on a real filesystem. That rules out the browser-based editing paths and any setup where the files are not actually on disk in a form Mix can read.

The activation events in the manifest make the trigger conditions concrete. The extension activates on the phoenix-heex and surface languages, on a workspace containing mix.exs, and on onDebugResolve:elixir, so it does not load in a workspace with no Elixir project. The repository also ships a .gitmodules file, an elixir-ls directory, syntaxes/ and a telemetry.json, plus walkthroughs/, which is the feature list VS Code shows on first install. The trade-off is deliberate and worth stating plainly: the accuracy you get comes from executing the project, and that is exactly the reason a workspace you cannot trust is refused.

## Running inside a dev container, and the troubleshooting list

ElixirLS can run inside a VS Code dev container for a consistent environment, and the README points at a separate elixir-ls-devcontainer-example repository holding a .devcontainer/Dockerfile. You copy that .devcontainer folder into your project, or use it as a starting point, then select Remote-Containers: Reopen in Container from the command palette, and after the container builds the extension runs inside it as it would locally.

The troubleshooting section is a short checklist of the things that actually break. You need hex and git installed, and github.com and hex.pm must be reachable, which may mean configuring an HTTPS proxy, and if your setup uses TLS man-in-the-middle inspection you may need to set HEX_UNSAFE_HTTPS=1. If ElixirLS fails to start, cleaning the Mix.install directory is the suggested fix, and the README gives the path to obtain it by calling Path.join(Mix.Utils.mix_cache(), "installs") from an iex session. There are also custom commands to restart ElixirLS with the command restart, to run mix clean or mix clean --deps in ElixirLS with the custom command mixClean, and a further restart option that the README truncates.

For the supported Elixir and Erlang versions, the README defers to the ElixirLS repository, which is where that information actually lives.

## Conclusion

vscode-elixir-ls fits a team writing Elixir who wants completion, go-to-definition, a debugger, incremental Dialyzer analysis and test discovery without leaving VS Code, and who trusts the code in their dependencies. It does not fit a security-conscious environment that refuses to execute project code, since the package declares untrustedWorkspaces as unsupported, and it does not fit a virtual workspace, which the package also rules out. Before you install it, read the untrusted workspace description in package.json, because compiling the project and running Mix tasks is exactly what gives you the accurate completion and the Dialyzer results, and that is also what makes the extension unsuitable for a workspace you do not trust.

## FAQ

### What does the vscode-elixir-ls extension provide?

It provides the Elixir language server and debug adapter for VS Code, powered by ElixirLS, an Elixir implementation of the Language Server Protocol and the Debug Adapter Protocol. The feature list includes code completion, debugger support, test discovery and running through the Test Explorer, automatic incremental Dialyzer analysis, go-to-definition, a mix task provider, a code formatter and multi-root workspace support.

### Why is this extension a fork of JakeBecker's vscode-elixir-ls?

The README says the elixir-lsp repository began as a fork when the original repository became inactive for an extended period, so an active fork could merge dormant pull requests and fix issues. The original repository has since been deprecated in favor of this one, and future updates to the original extension will come from this repository.

### Can the vscode-elixir-ls extension run in an untrusted workspace?

No. The package manifest declares untrustedWorkspaces as not supported, because ElixirLS compiles the project and runs Mix tasks, which executes code from the project and its dependencies, including compile-time code such as macros, mix.exs and dependency build scripts. Virtual workspaces are also unsupported, since Mix and the project files must be on a real filesystem.

### How do I customise the test runner in vscode-elixir-ls?

By providing a project launch configuration named mix test, which then becomes the default for running and debugging tests instead of the one the extension builds. The README shows an example using the mix_task type with debugAutoInterpretAllModules set to false and debugInterpretModulesPatterns set to a pattern list.

### Which Elixir and Erlang versions does the extension support?

The README does not state them and points to the ElixirLS repository for details on the supported Elixir and Erlang versions. The extension itself requires a VS Code engine version of ^1.105.0 and is published as version 0.31.1.

## Sources

- [elixir-lsp/vscode-elixir-ls on GitHub](https://github.com/elixir-lsp/vscode-elixir-ls)
- [Issues](https://github.com/elixir-lsp/vscode-elixir-ls/issues)
- [License: MIT](https://github.com/elixir-lsp/vscode-elixir-ls/blob/master/LICENSE)
- [Project website](https://marketplace.visualstudio.com/items?itemName=JakeBecker.elixir-ls)
- [README](https://github.com/elixir-lsp/vscode-elixir-ls/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/elixir-lsp-vscode-elixir-ls