Volar breaking changes

[Feinzer]

Problem description

Volar 1.0 had breaking changes on their end and neovim/nvim-lspconfig needs an update to handle it.

I tried modifying the snapshot commit for it and updating it manually, I then proceeded to change the setup config and set the typescript path to my own global installation however it still didn't work so I'm not sure if there's something else that needs an update.

Related:
neovim/nvim-lspconfig#2181
vuejs/language-tools#1916

LunarVim version

master-e4a5fe9

Neovim version (>= 0.8.0)

NVIM v0.8.0-1210-gd367ed9b2

Operating system/version

KDE Neon (Ubuntu) 20.04

Affected language servers

volar

Steps to reproduce

1. Install volar language server
2. Open any .vue file

Actual behavior

Outputs error, doesn't work

Expected behavior

It should work

support info

LspInfo

1 client(s) attached to this buffer:

Client: tailwindcss (id: 2, pid: nil, bufnr: [4])
filetypes: aspnetcorerazor, astro, astro-markdown, blade, django-html, htmldjango, edge, eelixir, elixir, ejs, erb, eruby, gohtml, haml, handlebars, hbs, html, html-eex, heex, jade, leaf, liquid, markdown, mdx, mustache, njk, nunjucks, php, razor, slim, twig, css, less, postcss, sass, scss, stylus, sugarss, javascript, javascriptreact, reason, rescript, typescript, typescriptreact, vue, svelte
autostart: true
root directory: ****
cmd: tailwindcss-language-server --stdio

Other clients that match the filetype: vue

Config: volar
filetypes: vue
root directory: ****
cmd: vue-language-server --stdio
cmd is executable: true
autostart: true
custom handlers:

Configured servers list: volar, tailwindcss

LvimInfo

Buffer info

• filetype: vue
• bufnr: 4
• treesitter status: active

Active client(s)

• name: tailwindcss
• id: 2
• supported filetype(s): [aspnetcorerazor, astro, astro-markdown, blade, django-html, htmldjango, edge, eelixir, elixir, ejs, erb, eruby, gohtml, haml, handlebars, hbs, html, html-eex, heex, jade, leaf, liquid, markdown, mdx, mustache, njk, nunjucks, php, razor, slim, twig, css, less, postcss, sass, scss, stylus, sugarss, javascript, javascriptreact, reason, rescript, typescript, typescriptreact, vue, svelte]
• attached buffers: 4
• root_dir pattern: 4
• capabilities: codeActionProvider | colorProvider | hoverProvider

Automatic LSP info

• Skipped servers: [angularls, ansiblels, csharp_ls, cssmodules_ls, denols, ember, emmet_ls, eslint, golangci_lint_ls, graphql, jedi_language_server, ltex, phpactor, psalm, pylsp, quick_lint_js, rome, reason_ls, solang, sorbet, sourcery, sqlls, sqls, stylelint_lsp, tflint, svlangserver, verible, vuels]

Formatters info

• Active:
• Supported: [eslint, eslint_d, prettier, prettier_d_slim, prettierd, rustywind]

Linters info

• Active:
• Supported: [eslint, eslint_d]

Code actions info

• Active:

logs

Error executing vim.schedule lua callback: /usr/share/nvim/runtime/lua/vim/lsp.lua:1285: RPC[Error] code_name = InternalError, message = "Request initialize failed with message: Cannot read properties of undefined (reading 'createLanguageService')"                                                                                                                                                                                                                        
stack traceback:
        [C]: in function 'assert'
        /usr/share/nvim/runtime/lua/vim/lsp.lua:1285: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

Screenshots

No response

[RamaHerbin]

Yeah I've got the same problem, I thought I did something wrong but now I understand

[2nthony]

seems to upgrade the nvim-lspconfig to the latest will fix this issue, and I think, the lunarvim stable version locks the nvim-lspconfig plugin version, so we can not upgrade 🤔.

not sure about the "locks version", but I can not upgrade any builtin plugins via :lvimSyncCorePlugins, :PackerUpdate or :PackerSync

now I am sure it locks the commit in the snapshot file https://github.com/LunarVim/LunarVim/blob/rolling/snapshots/default.json

[2nthony]

temporary solution

but note this will update all plugins to latest commit

• set vim.env.LVIM_DEV_MODE = true to your config.
• then run :lvimSyncCorePlugins or packer update/sync

in the stable version nvim-tree throw an error message, just add lvim.builtin.nvimtree.setup.view.height = nil to config

[Feinzer]

now I am sure it locks the commit in the snapshot file https://github.com/LunarVim/LunarVim/blob/rolling/snapshots/default.json

I was able to update only nvim-lspconfig editing the snapshots/default.json myself and running sync, but I was still getting the same error. Also tried clearing the cache and re-running sync, same issue. Not sure if I needed to update something else.

temporary solution

but note this will update all plugins to latest commit

* set `vim.env.LVIM_DEV_MODE = true` to your config.

* then run `:lvimSyncCorePlugins` or packer update/sync

in the stable version nvim-tree throw an error message, just add lvim.builtin.nvimtree.setup.view.height = nil to config

Thanks for the workaround

I believe we should have a hotfix release with these kinds of breaking changes or a way to manually unlock packages without editing the default.json file, potentially having a conflict when trying to update.

There might already be a way to do this but the documentation is lacking. I've been trying to understand the inner workings of the scripts better to contribute to the docs but I'm new to even Lua here so I don't think I'll contribute anything significant any time soon.

[2nthony]

@kylo252 @abzcoding

I think is really useful for cases like these.

my advice is: allow to override the snapshot as well, provide an option like:

-- to latest
lvim.packer.snapshots["nvim-lspconfig"].commit = nil
-- or specified a commit
lvim.packer.snapshots["nvim-lspconfig"].commit = "35a731b"

after this, run :lvimSyncCorePlugins will update nvim-lspconfig to the latest commit, and other plugins will keep the default commit.

using vim.env.LVIM_ENV_MODE = true is not a good idea for users.

---

so my lspconfig.lua can be like:

-- builtin

lvim.packer.snapshots["nvim-lspconfig"].commit = nil

local lsp = require("lspconfig")

-- unmap all preset buffer keymaps, use lspsaga instead
lvim.lsp.buffer_mappings.normal_mode = {}

lsp.volar.setup {
  filetypes = { 'typescript', 'javascript', 'javascriptreact', 'typescriptreact', 'vue', 'json' },
}

[kylo252]

my advice is: allow to override the snapshot as well

that's already possible in a Packer native way:

1. freeze a snapshot
2. edit the snapshot to your heart's desire
3. load the snapshot

see https://github.com/LunarVim/LunarVim/blob/rolling/lua/lvim/plugin-loader.lua#L10-L11

I'd consider overriding the default snapshot an advanced workflow anyway, so there's probably no need to create multiple ways to do the same thing.

[2nthony]

I tried the packer.snapshot, but it is not what I expected. because it is an A/B question, if I choose A(my snapshot), then I will never get B(lunarvim snapshot), that's why I prefer do "patch" via lunarvim itself.

thanks anyway!

[2nthony]

i figured out it is not just nvim-lspconfig needed to up-to-date, also mason and mason-lspconfig.

so I fix this issue via my new hack way, to let the above-mentioned plugins keep up-to-date.

https://github.com/2nthony/dotfiles/blob/main/.config/lvim/lua/hack/snapshot.lua

[kylo252]

I tried the packer.snapshot, but it is not what I expected. because it is an A/B question, if I choose A(my snapshot), then I will never get B(lunarvim snapshot)

hmm, that option is implemented in a weird, serial and very slooow way in Packer, that's why I ended up impelementing that logic, see #2751

what I had in mind was something more like this

:PackerSnaphot snap0
:e $LUNARVIM_CACHE_DIR/snapshots/snap0
" update whatever plugin you want
:PackerSnapshotRollback snap0

we're usually not that late with bumping the deps, I even made a CI workflow, but I still don't trust it 100% 😅

P.S. take a look at https://github.com/LunarVim/LunarVim/blob/e94390a9225c418dd96eb6b6822ce0dc15ce7cce/utils/ci/generate_new_lockfile.sh to see how to quickly generate a new snapshot

P.P.S. improvements are always welcome and highly apprecaited!

[2nthony]

yes, that's why it calls hack way. I did it because I:

• only need to update a few core plugins to the latest commit, other core plugins keep following lunarvim's default snapshot.
• don't want to maintain a new snapshot file for packer.

for stable reasons, I actually don't want to/should not contribute this hack to lunarvim, I think/believe there has a better way to handle it.😅

[2nthony]

P.S. take a look at e94390a/utils/ci/generate_new_lockfile.sh to see how to quickly generate a new snapshot

this is the point, plugins update is faster than lunarvim stable release, especially LSP servers.

but back to this issue 😅 , I think it won't frequently happen.

[aasutossh]

So, how to fix this?
I am getting the following error when opening vue files
I have latest version (0.9.0 neovim, and lunarvim rolling)

Error executing vim.schedule lua callback: ...r/neovim/HEAD-228a040/share/nvim/runtime/lua/vim/lsp.lua:1283: RPC[Error] code_name = InternalError, message = "Request initialize failed with message: Cannot
find module '/Users/aasutosh/.local/share/nvim/mason/packages/vue-language-server/node_modules/typescript/lib'\
Require stack:\
- /Users/aasutosh/.local/share/nvim/mason/packages/vue-language-server/node_modules/@volar/vue-language-server/out/nodeServer.js\
- /Users/aasutosh/.local/share/nvim/mason/packages/vue-language-server/node_modules/@volar/vue-language-server/bin/vue-language-server.js"
stack traceback:
        [C]: in function 'assert'
        ...r/neovim/HEAD-228a040/share/nvim/runtime/lua/vim/lsp.lua:1283: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

UPDATE:
deleting ~/.local/share/nvim (macOS) fixes the error not sure why.

[Feinzer]

UPDATE: deleting ~/.local/share/nvim (macOS) fixes the error not sure why.

Did you clean the cache after updating the packages? Sounds like that's the issue

Anyway this should now be fixed in the stable release, thank you everyone

[kylo252]

deleting ~/.local/share/nvim (macOS) fixes the error not sure why.

you probably needed to reinstall volar then, because that's where mason install servers