Introducing ElixirLS, the Elixir Language Server

I’ve been spoiled by good IDEs. Once you’ve gotten used to an IDE like RubyMine or IntelliJ IDEA, it’s hard to go back to just using text editors.

Elixir has an open-source IntelliJ plugin, IntelliJ Elixir, and it’s quite good. A few months ago, I started contributing to its development, adding ExUnit test support and debugger integration. It was fun to work on, but I got a bit frustrated with having to write Java. The IntelliJ Elixir codebase is all Java and it’s quite large — it includes an Elixir lexer and parser written in Java, among other code intelligence features.

There’s another approach that other editors are using — write the code insight logic in Elixir, and run a server in separate process that communicates with the editor or IDE. The original Elixir editor plugin that used this approach was Alchemist for Emacs, and the author published the Elixir code powering it as Alchemist Server. Another developer built upon Alchemist Server and created Elixir Sense which is being used in Atom and VS Code. With respect to IntelliJ Elixir, I’m convinced that the “language server” approach is the way to go because of the code reuse it enables.

It turns out, Microsoft has embraced this approach. They’ve published a JSON-based standard they’re calling the Language Server Protocol for IDE-agnostic language support, and it’s the standard way to write language plugins for VS Code. Red Hat is also backing the protocol and has added support for it to Eclipse Che. Microsoft also published a spec for a similar protocol for debugger integration, the VS Code debug protocol.

I’ve just released an early alpha of ElixirLS, a language server implementing these protocols for Elixir. It’s got debugger integration supporting line breakpoints, plus most of the standard editor features such as autocompletion and go-to-definition. It also reports build warnings and errors immediately as you type.

The server code is available here, and the associated VS Code extension is here.

I want to be clear that this is a very rough release. I’ve only tested it on OSX using Elixir 1.4, and it has significant known bugs. (The extension won’t even launch with Elixir 1.3, and most features don’t work properly for umbrella projects, for example.) I’m hoping to iron out the kinks in the coming versions, but right now, it can’t be considered stable. I’m hoping that the Elixir community might have some good ideas on how to improve it. If all you want is a stable editor for Elixir, stick with whatever you’re using now.

The best thing about having a standard protocol for IDE support is that it’s super easy to contribute to. You don’t have to know anything about VS Code or any other IDE. The spec is simple and well-documented — if you can write Elixir, you can contribute! If you’re interested in more of how it works, I’ve written a couple more blog posts on debugging Elixir in VS Code and on some of the compiler hacks I needed to enable reporting build warnings and errors as you type.

I hope other Elixir developers find it useful, or at least interesting. Give it a try, and happy coding!