# mason-lspconfig.nvim: bridging Mason and nvim-lspconfig on Neovim 0.11+

> mason-lspconfig.nvim installs language servers through mason.nvim and turns them on with vim.lsp.enable(). It is a thin bridge, and since Neovim 0.11 the plugin's job has shrunk. Here is what it still does, how to set it up, and where it fails.

**mason-org/mason-lspconfig.nvim** — Extension to mason.nvim that makes it easier to use lspconfig with mason.nvim.

- Repository: https://github.com/mason-org/mason-lspconfig.nvim
- Stars: 3,949 · Forks: 221
- Language: Lua
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/mason-org-mason-lspconfig-nvim

## The gap mason-lspconfig.nvim fills between Mason packages and LSP client names

Mason installs language servers as packages. nvim-lspconfig configures them as LSP clients. The two sides do not use the same names: the README gives the example of lua_ls on the lspconfig side mapping to lua-language-server on the Mason side. Someone has to hold that translation table, and that is the first responsibility the README lists for this plugin.

The second responsibility is lifecycle. Mason can put a binary on disk, but nothing starts an LSP client for it. mason-lspconfig.nvim watches what Mason has installed and calls vim.lsp.enable() for those servers, so a freshly installed server becomes live without you editing your config. The README also lists two smaller jobs: convenience APIs such as the :LspInstall command, and a handful of extra LSP configurations for servers that nvim-lspconfig does not ship.

The intended user is someone running Neovim 0.11 or newer who has already committed to Mason as their install path for tools. If you install language servers with your system package manager, this plugin has nothing to translate and nothing to enable.

## What Neovim 0.11 took away, and what is left

The README is unusually direct about scope reduction. It notes that since the introduction of vim.lsp.config in Neovim 0.11, "this plugin's feature set has been reduced," and it tells you to use the plugin if you want automatic enabling of installed servers or access to :LspInstall. Everything else that mason-lspconfig.nvim used to do around server configuration now belongs to core Neovim.

That reframing matters when you evaluate the dependency. You are not adopting a configuration framework. You are adopting a name translation layer, an auto-enable hook, and two commands. The default configuration block in the README contains exactly two settings, ensure_installed and automatic_enable, which is a fair measure of how much surface area is left.

The upside is that the plugin is unlikely to fight your own LSP setup, because it no longer owns that setup. The downside is that if you are looking for something to manage per-server settings, capabilities or keymaps, you are looking at the wrong layer and should be reading the Neovim LSP documentation instead.

## Installing mason-lspconfig.nvim and running a first server

Requirements come first. The README lists neovim >= 0.11.0, mason.nvim >= 2.0.0 and nvim-lspconfig >= 2.0.0. Setup is required, and the ordering is explicit: mason.nvim must be set up and nvim-lspconfig must be available in runtimepath before you set up mason-lspconfig.nvim.

With lazy.nvim, the README's recommended block declares both dependencies and passes opts, which means you do not call setup() yourself:

```lua
{
    "mason-org/mason-lspconfig.nvim",
    opts = {},
    dependencies = {
        { "mason-org/mason.nvim", opts = {} },
        "neovim/nvim-lspconfig",
    },
}
```

If you are not using lazy.nvim, install with your plugin manager and call setup directly. The README shows the minimal form:

```lua
require("mason-lspconfig").setup()
```

To make a server appear without hunting for it, open a file of the relevant type and run :LspInstall with no argument. The README states that with no server given, you are prompted to select one based on the current buffer's filetype. To pin servers up front instead, use ensure_installed, which the README describes as a list of servers to install if they are not already installed:

```lua
require("mason-lspconfig").setup {
    ensure_installed = { "lua_ls", "rust_analyzer" },
}
```

After either path, the server should be installed under Mason and enabled, because automatic_enable defaults to true. :LspUninstall takes one or more server names and removes them.

## automatic_enable is all-or-nothing unless you shape it

The default configuration sets automatic_enable = true, and the README warns that this only enables servers installed via Mason and will not recognize servers installed elsewhere on your system. That is the sharpest constraint in the plugin. A server you compiled yourself, or one your distribution packaged, is invisible to the auto-enable path even if nvim-lspconfig knows how to configure it.

The setting accepts three shapes, all shown in the README. Set it to false to turn the feature off entirely. Pass a table with an exclude key to keep specific servers out:

```lua
require("mason-lspconfig").setup {
    automatic_enable = {
        exclude = {
            "rust_analyzer",
            "ts_ls"
        }
    }
}
```

Or pass a plain list to enable only those servers, which the README illustrates with lua_ls and vimls. The distinction between the exclude form and the allow-list form is worth reading twice, because both are tables and a quick edit can flip your intent. An allow list silently disables every server you did not name.

The README does not document rollback behavior for ensure_installed, so it is not clear from the documentation what happens if an install fails partway through the list. The related searches around failed installs for yamlls, jsonls, ts_ls, lua_ls, bashls and vtsls suggest this is a common place to get stuck, and the README offers no troubleshooting section for it.

## Where mason-lspconfig.nvim is the wrong tool

If your language servers come from anywhere other than Mason, this plugin cannot help you. The README's note is unconditional: only servers installed via Mason are enabled. You would be adding a dependency that translates names for packages you do not have and enables nothing.

If you are on Neovim 0.10 or earlier, the requirements rule the plugin out. The stated minimum is 0.11.0, and the README's own framing ties the plugin's reduced role to the vim.lsp.config API introduced in that release. Downgrading the plugin to fit an older Neovim is not a path the documentation describes.

There is also a narrower case: if you want one server with a hand-written configuration and you are happy to call vim.lsp.enable() yourself, the bridge adds a translation table and an auto-enable hook you will spend time excluding. The exclude form of automatic_enable exists precisely for this, but configuring an exclusion to get back to where you started is a sign the plugin is not earning its place in your config.

## How it compares with plain nvim-lspconfig plus Mason

The alternative is to run mason.nvim and nvim-lspconfig side by side and wire them yourself. Mason still installs the binary; you call vim.lsp.enable() for each server you want, and you keep the lua_ls to lua-language-server name mapping in your own head or your own config.

That approach costs you a line per server and removes a dependency. It also removes the automatic_enable behavior, which is the feature the README tells you to adopt the plugin for. If you install servers rarely and prefer explicit config, the manual route is defensible and has fewer moving parts to debug when a server does not start.

mason-lspconfig.nvim wins when the set of servers you use changes often, or when you want ensure_installed to make a fresh machine converge on your expected toolchain. It also wins on naming: the translation between lspconfig server names and Mason package names is maintained upstream rather than in your dotfiles, which is the kind of thing you notice only when it breaks. Neither approach changes how Neovim itself handles LSP; the difference is bookkeeping.

## Maintenance, licence and the cost of keeping up

The repository is not archived, and the last push was on 2026-09-22. Releases are not frequent: v2.3.0 on 2026-06-11, v2.2.0 on 2026-04-23, and v2.1.0 before that on 2025-07-29. The gap between v2.1.0 and v2.2.0 is roughly nine months, so treat this as a plugin that moves in steps rather than continuously.

The upgrade cost is concentrated in the version floors. The README requires mason.nvim >= 2.0.0 and nvim-lspconfig >= 2.0.0 alongside Neovim 0.11.0, so a major bump in either dependency can force a coordinated update. Because the plugin's remaining surface is two settings and two commands, the blast radius of such an update is small, but the floors are hard: the plugin will not carry you across an older Neovim.

Licensing is Apache-2.0 per the repository's LICENSE file. That is a permissive licence with an explicit patent grant and a requirement to preserve notices, but this is a description of the file, not legal advice; read the licence text and your own obligations before redistributing anything derived from it.

## Conclusion

Adopt mason-lspconfig.nvim if you already use mason.nvim and want installed servers enabled without a per-server vim.lsp.config block; the automatic_enable and ensure_installed settings are the whole value proposition. Skip it if you install language servers outside Mason, since the README states the plugin only enables servers installed through Mason, and skip it if you are still on Neovim 0.10 or older, because the requirements section asks for neovim >= 0.11.0. Before relying on it, confirm your mason.nvim is at 2.0.0 or later and that nvim-lspconfig is on your runtimepath before you call setup(), then run :LspInstall with no argument on a file whose server you are missing and read the prompt.

## FAQ

### What does mason-lspconfig.nvim do?

It bridges mason.nvim and nvim-lspconfig. The README lists its responsibilities as automatically installing and automatically enabling (vim.lsp.enable()) installed servers, providing convenience APIs such as :LspInstall, adding a few extra LSP configurations, and translating between nvim-lspconfig server names and mason.nvim package names.

### Is nvim-lspconfig deprecated in Neovim?

The README does not say nvim-lspconfig is deprecated. It says that since the introduction of vim.lsp.config in Neovim 0.11, mason-lspconfig.nvim's own feature set has been reduced, and it still lists nvim-lspconfig >= 2.0.0 as a requirement.

### How do I install mason-lspconfig.nvim?

Install it with your plugin manager and call require("mason-lspconfig").setup(), with mason.nvim set up and nvim-lspconfig available in runtimepath first. Under lazy.nvim the README's recommended block sets both up as dependencies and passes opts, so you never call setup() yourself.

### What is Mason for Neovim?

mason.nvim is the package manager that installs the language servers; mason-lspconfig.nvim is the extension that connects those installed packages to nvim-lspconfig and enables them. The README requires mason.nvim >= 2.0.0 for the bridge to work.

## Sources

- [Issues](https://github.com/mason-org/mason-lspconfig.nvim/issues)
- [License: Apache-2.0](https://github.com/mason-org/mason-lspconfig.nvim/blob/main/LICENSE)
- [mason-org/mason-lspconfig.nvim on GitHub](https://github.com/mason-org/mason-lspconfig.nvim)
- [README](https://github.com/mason-org/mason-lspconfig.nvim/blob/main/README.md)
- [Releases](https://github.com/mason-org/mason-lspconfig.nvim/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mason-org-mason-lspconfig-nvim