Add volar #1223

sethidden · 2021-09-05T11:13:41Z

After the release of Vue 3 there arose a need of a new language server that suppors the new syntax.
We already have vuels in the repo (so that's the one that existed pre-Vue 3) and the new volarvuels I'm adding here that supports the new syntax.

https://github.com/johnsoncodehk/volar

https://github.com/johnsoncodehk/volar#communitys-language-client-implements - it's supported in many vim lsp configuration providing extensions, I'm just adding it also here :P

See vuejs/language-tools#441

Problems:

If this is merged we'll have vls, vuels and volarvuels which makes things even more confusing, since vuels is normally vls, but vls is taken by the V language server, so this repo uses vuels instead. But now we have volarvuels. AND there's also https://github.com/vuedx/languagetools/tree/main/packages/vue-languageservice which is a third language server for Vue Decided on just volar
It's actually crucial to pass serverPath. I'll need to look at angularls's code to detect it dynamically
Improve docs - I assume as long as the nvim set-rtp command from CONTRIBUTING.md has the word 'volar' I'm good. Since it's not modifying the CONFIG.md for me locally
~~bin_name uses volar-server, which I got from the AUR. Better wait for Expose @volar/server/out/index.js as executable in $NPM_PREFIX/bin vuejs/language-tools#458~~ - fixed because newest alpha version exposes vue-server binary. ~~Let's still wait for this to stabilize~~ Volar's maitainer's words sound like it's gonna be a while until this changes
~~Run linters, right now it probably has lots of lint errors~~

lua/lspconfig/volarvuels.lua

sethidden · 2021-09-05T19:44:17Z

Is the language server in this PR slow for anyone else? I open a .vue file and errors appear after around 12 seconds. Did I enable some resource-heavy options?

johnsoncodehk · 2021-09-05T19:50:24Z

Is the language server in this PR slow for anyone else? I open a .vue file and errors appear after around 12 seconds. Did I enable some resource-heavy options?

Initialization time is proportional to your project scale, at least need a few seconds, Volar exchanges this for better runtime performance. vuejs/language-tools#455 can improve this problem.

mjlbach · 2021-09-07T05:37:43Z

lua/lspconfig/volar.lua

+local bin_name = 'volar-server'
+
+-- https://github.com/johnsoncodehk/volar/blob/master/packages/shared/src/types.ts
+local volar_init_options = {


Do all of these options need to be explicitly set, or are these overriding defaults? General question, not just limited to this section.

Yes, need explicitly set to enable these features. Otherwise features was disabled.

Thanks! If you could, since you are the expert, please let me know if anything needs to change in this PR regarding settings or init_options.

The options look good to me! And no need to specifically set false for unsupported features, it will just ignore if unsupported.

Just wanted to be explicit

sethidden · 2021-09-07T07:16:09Z

lua/lspconfig/volar.lua

+local volar_settings = {
+  volar= {
+    codeLens= {
+      references = true,


@mjlbach Regarding your comment above about "is it necessary to set those explicitly". init_options need to be explicit, but volar_settings contains some things that basically set some settings to their default value. Here I'm setting references to true, but it's already true by default: https://github.com/johnsoncodehk/volar/blob/26b36fb01a83a68c94fcedd06144041876a7ae69/package.json#L78

I assume you'd like a minimal config that overrides defeaults only when it's necessary to make the LS work with nvim?

On the other hand, I'm worried people won't know about the settings = {} prop in nvim_lsp.volar.setup{}, since most LSs use init_options

Would it be ok to do something like

init_options = volar_init_options, -- https://github.com/johnsoncodehk/volar/blob/master/package.json#L42 settings = {}

?

I would just use the package.json to autogenerate the documentation for these optiosn (see pyright or other servers, it's just one line with the url to the package.json). I find people get extremely confused when we duplicate default settings, so we should only override when nececssary.

86431d9

Done. I also changed the link to package.json in a later commit, since the previous one didn't have a "contributes" property

lua/lspconfig/volar.lua

mjlbach · 2021-09-07T07:18:19Z

lua/lspconfig/volar.lua

+    Do not run `vuels` and `volarvuels` at the same time. 
+    To check which language servers are running, open a `.vue` file and run the `:LspInfo` command.
+    ]],
+    default_config = {


What's in default_config should get automatically pulled during docgen, you can test locally but I think it's unnecessary here

I checked locally. Indeed it gets fetched :)

ce7a7e0

lua/lspconfig/volar.lua

mjlbach · 2021-09-07T18:28:15Z

lua/lspconfig/volar.lua

+-- https://github.com/johnsoncodehk/volar/blob/master/packages/shared/src/types.ts
+local volar_init_options = {
+  typescript = {
+    serverPath = get_typescript_server_path(vim.fn.getcwd()),


this vim.fn.getcwd seems brittle, should it not use rootdir? This can be done in on_new_config if necessary.

This is inspired by

nvim-lspconfig/lua/lspconfig/angularls.lua

Line 15 in 08a698d

local default_probe_dir = get_probe_dir(vim.fn.getcwd())

Perhaps vim.fn.cwd() is warranted in case of angularls's probedir but weird for detecting typescript in this PR

I'll try to fix this with on_new_config, thanks :)

Done f170b0c

I'm not sure if intentionally not providing serverPath in init_options to Volar (eg in volar.setup{init_options={}} is a mistake. Anyhow, I preferred the user to get an error from Volar in that case rather than get some vague lua error about "index is nil".

Hence the if chain check

johnsoncodehk · 2021-09-07T20:28:52Z

@mjlbach if possible, I hope we can split features to multiple language server, because the DX will be much better. Can nvim-lsp do that?

References:

mjlbach · 2021-09-07T22:31:40Z

Yes, but the API for doing it declaratively is a bit annoying, we basically have a hook after start_client to disable detected server capabilities inon_attach

sethidden · 2021-09-08T13:44:29Z

Yes, but the API for doing it declaratively is a bit annoying, we basically have a hook after start_client to disable detected server capabilities inon_attach

Is there an example of this somewhere in the repo? I can't wrap my head around what that'd look like.

Do you mean that the implementation would need to:

intercept settings that come to volar in on_attach (after requirelspconfig.volar.setup{})
categorize capabilities and assign them to the 2-3 volar instances
launch them by directly calling built-in vim.lsp methods - so bypassing the nvim-lspconfig abstraction layer

My first reflex when thinking about mapping these lines https://github.com/yaegassy/coc-volar/blob/master/src/index.ts#L82-L86 from the coc-volar implementation to nvim-lspconfig would be

configs['volar-server-1-api'] = {
  init_options = {languageFeatures = { --[[ all languageFeatures ]]--}}
}

configs['volar-server-2-document'] = {
  init_options = {documentFeatures = { --[[ all documentFeatures ]]--}}
}

but that feels naive and probably would add unnecesary entries to CONFIG.md

mjlbach · 2021-09-08T15:15:55Z

When you say "multiple language servers", do you mean mutiple instances of volar? That might be kind of challenging. I'd have to think about it a bit, as it's not something with explicitly support.

Hypothetically you could do something like (contrived example):

vim.lsp.volar.setup{
  on_attach = function(client)
    client.resolved_capabilities.document_formatting = true
  end;
}
vim.lsp.volar.setup{
  on_attach = function(client)
    client.resolved_capabilities.document_formatting = false
  end;
}

In the case of volar, you could just diable these in initOptions as well.

But that shouldn't work with our current autocommands. This isn't a very common pattern, but I'm not opposed to adding support for it.

mjlbach · 2021-09-08T15:20:42Z

Can you address lint/style lint/commit lint issues and then I'll merge? You can just run stylua in the base directory, and then interactive git rebase (or I'll do it for you)

mergify · 2021-09-08T15:42:32Z

This pull request has been automatically closed by Mergify.

mergify · 2021-09-08T15:42:33Z

CONFIG.md is auto-generated: edit the lua source file instead (and re-read the PR template).

mjlbach · 2021-09-08T15:43:39Z

Seems like a bad rebase :)

sethidden · 2021-09-08T15:44:41Z

@mjlbach do you mean "use git rebase --interactive to drop the merge commits because here we prefer rebases"? :P not sure if I understand correctly

mjlbach · 2021-09-08T15:46:15Z

No, I mean I want you to squash your commits and write a "conventional commits" style commit message haha.

sethidden · 2021-09-08T16:24:56Z

Thanks for your supervision guys :)

@johnsoncodehk Can you take a look at #1223 (comment) ?

I understood that there should be multiple instances of volar that handle different features (eg. if you open htop/task manger you'd see 2-3 volar processes) - is this correct?

johnsoncodehk · 2021-09-08T16:27:49Z

@johnsoncodehk Can you take a look at #1223 (comment) ?

If my understanding is correct, it means that we cannot simply configure it. We need to wait for nvim-lsp to improve its support.

I understood that there should be multiple instances of volar that handle different features (eg. if you open htop/task manger you'd see 2-3 volar processes) - is this correct?

Yes, it should have 3.

mjlbach · 2021-09-08T16:29:34Z

To clarify, it's an lspconfig limitation not a built-in client thing (they are separate, you don't need to use this repo to use the built-in client)

sethidden · 2021-10-17T21:39:06Z

@mjlbach Regarding multiple language servers for volar, I came up with this:
vuejs/language-tools#606

Would you say it'd be acceptable to remove the current volar config and have the volar.lua file register three configurations - volar_doc, volar_api and volar_html? Then the user would need to call volar_doc.setup{}, volar_api.setup{}, volar_html.setup{} (if you forget to start one of them you'll get reduced functionality)

Or there could be 4 configs - volar, volar_api, volar_doc, volar_html (all under the same entry in the "supported LSs" in the README.md table)

Or I could just publish a separate neovim plugin that registers those configurations. Though this is suboptimal as I feel as Volar expects multiple LS to be default