Declarative extensions

[maxnordlund]

I've been using Zed as my main editor for a few months now and really appreciate all the thought that went in to the fundamentals behind the extensions (e.g. using WASM/WASI).

However I've noticed the official/well maintained ones supports downloading language servers¹, while the less polished ones² does not. So I read through their source and realized they look very boilerplatey. This makes me think that most of the current set of features can be done declaratively in the extension.toml.

Let's take the Elixir extension as an example. It supports three different LSP's, but with varying level of support for their settings. Only Lexical seems to support custom startup arguments. But I digress, here's the extension manifest at the time of writing this:

extension.toml

id = "elixir"
name = "Elixir"
description = "Elixir support."
version = "0.1.7"
schema_version = 1
authors = ["Marshall Bowers <elliott.codes@gmail.com>"]
repository = "https://github.com/zed-extensions/elixir"

[language_servers.elixir-ls]
name = "ElixirLS"
languages = ["Elixir", "HEEX"]

[language_servers.next-ls]
name = "Next LS"
languages = ["Elixir", "HEEX"]

[language_servers.lexical]
name = "Lexical"
languages = ["Elixir", "HEEX"]

[grammars.elixir]
repository = "https://github.com/elixir-lang/tree-sitter-elixir"
commit = "a2861e88a730287a60c11ea9299c033c7d076e30"

[grammars.heex]
repository = "https://github.com/phoenixframework/tree-sitter-heex"
commit = "008626a3fad379d17c81d5ed576edd9bd7a4fbf7"

The code for next-ls is in https://github.com/zed-extensions/elixir/blob/main/src/language_servers/next_ls.rs

Now imagine we could specify that in TOML instead:

[language_servers.next-ls]
name = "Next LS"
languages = ["Elixir", "HEEX"]
download = "https://github.com/elixir-tools/next-ls/releases/download/{version}/next_ls_{os}_{arch}{maybe_exe_extension}" # or v{version}
executable = "next-ls"
arguments = ["--stdio"]

[lanugage_servers.next-ls.env]
MIX_ENV = "test"

I'm sure I've glossed over some intricate detail that makes this less then straight forward. Some will still need the full power of being compiled, but I believe that most extensions could be reduced to being purely declarative. The extension code could either be generated on the fly, or some sort of generic implementation for declarative extensions only. The former would be backwards compatible, which is nice.

The real upside would be support for more features across the board. I'm mostly thinking of the customization of the sever command, arguments, and environment. But also customization of the initialization request sent in the very beginning (for example to enable/disable completion or inline formatting), and sending a "workspace configuration" request shortly after. These customization's vary wildly between different extensions, and even within one. Only one of the three language servers in the Elixir extension supports custom server arguments, and as far as I can see, none supports customization of the server environment.

Footnotes

1. Among other features, mostly regarding starting and configuring language servers. ↩

2. It doesn't have an LSP, but there's a PR for it. ↩