Hacker News Reader

Comment by c-hendricks | Hacker News Reader

I unintentionally ran the main branch when testing some changes and a lot of my config broke (mostly around LSPs, CodeCompanion was much slower streaming its responses) so might wait a bit before upgrading.

View on HN

The lspconfig depreciation was a very painful upgrade for me too, as it seems to be very poorly documented; but ultimately it came down to moving all of the LSP server configuration to `vim.lsp.config` blocks, then calling `vim.lsp.enable` with all the servers I use.

I’m still not clear on what Mason is doing in my config after the switch but oh well.

It's documented here (with migration steps):

https://github.com/neovim/nvim-lspconfig#important-%EF%B8%8F

and in a pinned issue.

and nvim-lspconfig :help has a migration guide:

https://github.com/neovim/nvim-lspconfig/blob/16812abf0e8d81...

It's still not super intuitive with a non-trivial config and plugins. I had enough things that hooked into LSP (Mason, linting, inlay hints, etc.) that I needed to spend a couple of weekend afternoons moving my configs over. For a lot of my config it was an all or nothing migration.

Mason installs LSP servers (and other tooling if desired). So if you're managing your LSP servers elsewhere (distro package manager, etc), it's probably not doing much.

Mason was always just a package manager for LSP servers. It used to be you needed the nvim-lspconfig plugin to properly configure LSP servers to work with neovim; to help with that there was the mason-lspconfig plugin that basically mapped LSP servers (as installed by mason) to nvim-lspconfig LSP configurations to make it all Just Work.

Now nvim-lspconfig and mason-lspconfig are no longer required thanks to the `vim.lsp.config`/`vim.lsp.enable` setup so you don't need them unless you want the little bit of automagic setup. Mason you can retain if you find it easier to install LSP servers through it, otherwise you can drop that too. Personally I manage my LSP tooling through distro/mise and replaced the lspconfig plugins with just a few autocommands and manually grabbing the config files from nvim-lspconfig git repo as needed.

I had the same issue with LSPs. If you have LSP configurations in a dedicated lsp directory all you need to do is instead of calling this:

vim.lsp.config(<lsp server>, config)

just return the config as a table i.e

vim.lsp.config("emmet_ls", { filetypes = { "html", "css", "sass", "scss", "less", "svelte", "gotmpl", }, })

will become

return { filetypes = { "html", "css", "sass", "scss", "less", "svelte", "gotmpl", }, }

in lsp/emmet_ls.lua - file name is very important btw

I may have worded that poorly. My config, specifically around LSPs was wonky. I did the old migration of configuring LSPs a while ago, but on the master branch I'd randomly get errors printed.

Update: after updating everything the errors have disappeared, phew.

Reply on news.ycombinator.com