Introducing mason.nvim

[williamboman]

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:

1. Uninstall all of your installed servers. mason.nvim is not compatible with nvim-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
   :LspUninstallAll command.

2. Remove nvim-lsp-installer and add mason.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" }

3. Set up mason.nvim in your Neovim init script. Refer to :h mason-default-settings & :h mason-lspconfig-default-settings for 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.

[ya2s]

I'm not happy with the more plugins I have to install, do I need mason-lspconfig.nvim?
Why did you split into two plugins?

[eeeXun]

Author mentions there mason-org/mason.nvim#109

[vladdoster]

This comment makes no sense. Mason replaces nvim-lsp-installer, and has new features such as installing formatters and linters.

The initial post states:

[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 :).

[TornaxO7]

Is this repo going to be archived?

[williamboman]

Nope!

[TornaxO7]

May I ask for the reason?

[williamboman]

When archiving a repo it becomes entirely frozen and I'd like to keep it open. This plugin still see a lot of usage and while I haven't committed to any support guarantees I'd say the current status resembles one that is somewhere between the traditional LTS and EOL policies. I'll be observing usage trends and if they're not trending in the right direction I'll gradually do more to nudge users to migrate.