Introducing mason.nvim
mason.nvim is the next generation version of nvim-lsp-installer. It builds on top of the very same foundation as nvim-lsp-installer, but with a majority of internals refactored to improve extensibility and testability.
More importantly, the scope of mason.nvim has also been widened to target more than just LSP servers. mason.nvim supports DAP servers, linters, formatters, and more. As of writing, mason.nvim provides 150+ packages for 100+ languages. It can be thought of as a general-purpose package manager, native to Neovim, that runs everywhere Neovim runs (Windows, macOS, Linux, etc.).
Another big change with mason.nvim is that executables are now linked to a single, shared, location, allowing seamless access from Neovim builtins (shell, terminal, etc.) as well as other 3rd party plugins.
There have also been other improvements such as broader test coverage, more documentation, and a revamped UI!
What's the future of nvim-lsp-installer?
nvim-lsp-installer will no longer be actively maintained, meaning I won't be doing things like porting new mason.nvim packages to nvim-lsp-installer, monitoring lspconfig for changes that require updates, or put much effort into user support or bug issues (the recommendation for the latter will be to migrate to mason.nvim).
Why? 
As more and more workflows and editing capabilities finds it way into the Neovim ecosystem (LSP, DAP, null-ls to name a few popular ones) there's an ever-increasing dependency on external tooling to be installed. While in many cases the process of installing this external tooling is simply a matter of a single command, discovering new tooling as well as managing your installed ones quickly gets complicated.
mason.nvim provides a single, Neovim native, interface for all of this, allowing you to get up and running in a matter of seconds. All packages are installed into a single location, allowing you to do things such as (i) easily backup your external dependencies, (ii) not require root to install something, and (iii) mount it as a volume in ephemeral Docker containers.
Why not continue the work in nvim-lsp-installer?
nvim-lsp-installer is very tightly coupled with lspconfig, increasing its scope would not only be awkward but it would very likely come with lots of breaking changes (something I've been careful not to introduce in the past). With more and more LSP-related capabilities continuously being added to Neovim core, setting up LSP servers without going through lspconfig is becoming more of an option. Oh also, the name of the plugin would also be very misleading :).
Migrating from nvim-lsp-installer to mason.nvim
Migrating to mason.nvim should be rather easy. The following steps are a recommendation that highlights things to pay attention to:
-
Uninstall all of your installed servers.
mason.nvimis not compatible withnvim-lsp-installer's file hierarchy.
Make sure to uninstall your existing servers to free up disk space. This can either be done manually, or via the
:LspUninstallAllcommand. -
Remove
nvim-lsp-installerand addmason.nvim&
mason-lspconfig.nvim. If you use a plugin manager, update
your configuration accordingly, example:
- use { "williamboman/nvim-lsp-installer" } + use { "williamboman/mason.nvim" } + use { "williamboman/mason-lspconfig.nvim" }
-
Set up
mason.nvimin your Neovim init script. Refer to:h mason-default-settings&:h mason-lspconfig-default-settingsfor more details.Note that some settings have been renamed, for example
ui.icons.server_installed -> ui.icons.package_installed.If you still use the old, deprecated,
.on_server_ready()API, see this discussion first.
- require("nvim-lsp-installer").setup { - ensure_installed = { "sumneko_lua" }, - ui = { - icons = { - server_installed = "โ" - } - } - } + require("mason").setup { + ui = { + icons = { + package_installed = "โ" + } + } + } + require("mason-lspconfig").setup { + ensure_installed = { "sumneko_lua" }, + }
Other things worth paying attention to is that the package names in mason.nvim no longer follow the lspconfig naming scheme, but instead follows upstream naming schemes (so for example, sumneko_lua is now lua-language-server). The mason-lspconfig extension helps translate these names, more info in docs.