Hi all,
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.
TLDR
- 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
project-workspace-detection
repository - the ācoreā of lspconfig will be moved into a new project module in core
Intro
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 will be subsumed by features in neovim core
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
Projects (neovim/neovim)
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.
neovim/server-configurations
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.
neovim/workspace-patterns
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.
Wonāt this make things more complicated?
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
Creation of server specific plugins
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ā¦
The need for an opinionated automagical meta-plugin
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:
- autocompletion
- snippets
- 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 nvim-lsp-installer
, navigator.lua
, 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.
Ask questions, get involved
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.