Kinda long-winded and subject to change, be warned.
lspconfig has reached what I would consider a stable state. I want to talk about what I foresee as the future of
lspconfig and the next phase of the neovim lsp ecosystem.
- lspconfig will be renamed server-configurations
- everything but the individual server configurations and documentation will be removed from lspconfig and replaced with comparable functionality in core.
- root_dirs will be moved out to a generic
- the “core” of lspconfig will be moved into a new project module in core
First off, I want to say I think with neovim 0.6.1, we have finally hit what I would call
stable. Most things are now bug-free (36 issues across lspconfig and core!), and while there are still a few known features missing (semantic tokens, workspace watchers), I think the built-in client is solid and fast.
That being said, I think now is the time to start thinking about what comes next and solicit feedback.
lspconfig has served it’s purpose well as a stop-gap for configuring the built-in client. It offers many things “close” to project level configuration, but I believe the configuration paradigms it encourages are fundamentally broken by the growing trend of using multiple language servers.
lspconfig users treat the lspconfig
config object as a form of project management, using
on_attach to set up keybindings, autocommands, and even buffer options. This becomes problematic when you have two language servers fighting with the same
on_attach. Many users want to conditionally dispatch certain functions to one server or the other, they want a single unified set of settings for a given project’s buffers.
Basically lspconfig will be merged into core, and the remainder will be split across two separate repos
I’m proposing a
Project as the atomic unit for server management and configuration. A project configuration would be something like this: project.lua · GitHub. The main idea is to unify the on_attach to operate for the collection of servers (and other features) over the project directory. The project code would live in neovim croe.
lspconfig as it stands would be renamed to
server-configurations. The only thing that would remain is the server configurations stored under
lspconfig/server_configurations. These would also be stripped of
root_dir. The main purpose of this repo would be to provide the “sane” defaults": settings, initializationOptions, and the cli args for launching the servers.
It’s never made much sense to me that root_dir is tied so directly to language servers. Really, root_dir is about detecting project roots which is based on the language packaging conventions. As projects are “bigger” than language servers, these would be decoupled from lspconfig and moved into their own repo.
I think this makes things more verbose but less complicated. I see many anti-patterns (disabling capabilities to make null-ls the default formatter, wrapping lspconfig to allow imperative installation of language servers) that this pattern solves.
For those that want an extremely simple experience (vscode, coc, whatever) this is mostly about backend restructuring, I have a plan for you
By moving all of the
lspconfig infrastructure into core, I hope to spawn a new wave of language-server specific plugins. Right now,
lspconfig offers some support for things off protocol. I’ve tried to discourage this in favor of server specific plugins, but it’s hard.
null-ls ended up having to copy/paste the entire lspconfig infra. By moving the concept of a
Project to core, plugins can reuse this by either providing utility functions that users can add to their own projects, or even providing wholesale project templates that combine multiple language servers, formatters, and opinionated settings into one, which brings me to…
I see many complaints about “lspconfig being hard to set up”. Here is what I understand people to want:
a single installation line `use ‘nvim-lsp/my_automagical_plugin’ enables:
- automatic installation of servers when you open a filetype
- automatic launching of a preferred language server when you open a filetype
- project templates (think react, vue, basically anything webdev which invites multiple language servers
- off-protocol support for all language servers
- support for launching the language server
- sane default keybindings
Snippets and autocompletion may some day make their way into neovim core, the rest will likely not.
I personally would not use or develop this meta-plugin, but I’m hoping my efforts to expose/build the requisite APIs in the built-in client, and the upcoming projects module (when it’s ready, etc.) will make building this meta-plugin easier.
I think there is a lot of duplicate effort amongst
lunarvim, other frameworks, etc. that could be pooled into this effort. The biggest blocker, IMO, right now is the lack of dependencies in most package managers, and the fact that most package managers do not expose an imperative API a package can use to dynamically fetch additional dependencies at runtime.
Anyways, that’s kinda messy but wanted to loop people in. None of this is set in stone, I just wanted to provide some future “direction” for people interested in contributing to the ecosystem.