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 <[email protected]>"]
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. ↩

[xpe]

@maxnordlund I like the direction of your thinking! I wonder if you have thought more about this question: What are some good ways to provide a declarative syntax that can coexist with fully custom extensions -- even in the same extension? If there is a good design for this, it can offer a nice range of options -- kind of an "a la carte" set of options.

[maxnordlund]

Since there's already a manifest file I think it's the natural place for this. I think a build step (build.rs maybe?) that generates the current boilerplate from the manifest would be best. You would still have a Cargo file and entry point, just nothing else in lib/foo.rs. If you want to switch to manual mode you copy the generated output back to the source and hack away.

Precisely what kind of boilerplate/module structure, if this needs some procedural macro as well, etc I'll leave to the experts.

[xpe]

As a meta-response, it would be very interesting to write an automated analysis program that ingested all Zed extensions and then surfaced common elements of extensions. This could provide data for exploring different declarative extension designs and choices.

Maybe even think of it sort of like a "linting" or "automated migration" feature ... it would guide an extension author towards reusing common declarative blocks (when suitable).

[lnay]

Note that this will only be relevant for extensions which download from GitHub releases, many extensions will use an NPM package instead. Would there start to be multiple declarations for different options? Having a good example or small crate for extensions to use could be an alternative idea.

The real issue here is that the fish extension has not been touched in a year despite it receiving pull requests, including from the Zed team, and also that it does not register a language server to begin with.

[xpe]

The real issue here is that the fish extension has not been touched in a year despite it receiving pull requests, including from the Zed team, and also that it does not register a language server to begin with.

I'm not following how this is connected to this particular issue. What am I missing?

[lnay]

It's connected in the sense that it was referenced in the discussion as an extension which did not have a language server download implemented.

[xpe]

@lnay Ah, I see now. CTRL-F didn't find it, since it was in the hyperlink, not the plain text. I see it now, linked from "less polished ones":

However I've noticed the official/well maintained ones supports downloading language servers1, while the less polished ones2 does not.

[maxnordlund]

There's already special support for GitHub releases, but I imagine adding similar support for common scenarios like npm/npx or uv/uvx for Python¹ could be worthwhile. I know the official MCP servers prefer Docker, so that might also be a good candidate.

The best would be to use the native dependency management so stuff like Dependabot/Renovate works.

The real issue here is that the fish extension has not been touched in a year despite it receiving pull requests, including from the Zed team, and also that it does not register a language server to begin with.

The fish extension is just an example. And although I would love to see it moved to zed-extensions and updated, that's a separate issue.

Footnotes

1. I think it should be up to Zed to choose how to run a package. That way it can manage the runtime for you/switch as needed when new, better implementations arrive. Case in point, pipx handles the virtualenv just fine but relies on existing python, whereas uv manages both python and the virtualenv. ↩