Dynamic enable/disable tsserver/denols

[johnpyp]

It would be awesome to have intelligent context switching between Deno and Tsserver natively integrated into this plugin... for example heuristically checking package.json / deno.json, or if the file has a hashbang, checking if it has deno or node in it.

[sigmaSd]

That's not really feasible

• node is easy , detect package.json
• deno in the other hand, you have to guess the user intent, deno can work with only the javascript file, or with deno.json or with package.json (yes deno supports running scripts from package.json natively)

The deno manual, recomends using Deno.enablePaths for this use case https://deno.land/[email protected]/references/vscode_deno#partially-deno-enabling-a-workspace

You can use such lsp settings locally using neoconf , or lsp-settings https://github.com/sigmaSd/deno-nvim#local-settings

[sigmaSd]

This is for a mixed workspace ofc, I you mean different projects , thats already possible by specifying the root path when setting up the lsp, for example here is what I use

lspconfig.setup("tsserver", {
  root_dir = require "lspconfig.util".root_pattern('package.json'),
  --  ... more options
})

require("deno-nvim").setup {
  server = {
    root_dir = require "lspconfig.util".root_pattern('deno.json', 'deno.jsonc', 'denonvim.tag'),
   --  ... more options
}

[johnpyp]

One thing this wouldn't easily solve is something like the hashbang usecase right?

For me, I'm interested in using Deno for a replacement for bash scripting, but with single file support conflicting between them Deno and tsserver it isn't that viable, and I don't really want deno.json files littered in random script dirs.

[sigmaSd]

One way to improve the situation is to add single_file_support = true to deno and single_file_support = false to tsserver, since tsserver doesn't really work with a single file, it needs package json, this will make any js/ts work with deno

helix can run an lsp based on the shebang (but it doesn't work as expected last time I tried it) probably lspconfig can be extended to do something similar,

[johnpyp]

Hmm yeah that helps, though it doesn't make it quite seamless, as when I tried that Deno started getting enabled in random node projects too.

https://github.com/LumaKernel/vim-tsdetect seems to take the heuristic based approach for coc-tsserver / coc-deno, and the logic seems pretty reasonable, but it's all written in typescript and is coc-specific of course.

Do you think something similar could be implemented in this plugin?

[sigmaSd]

Such heuristics are out of scope for this plugin , also its not perfect, for example there are deno projects that use node_modules (some npm deps requires it, and you need to pass --node-modules-dir to deno)

The problem is deno really want a workspace, since the official way in vscode, is to create a .vscode dir with deno settings ,

I used to have a structure like this

-deno-scripts-denonvim.tag
             |-script-dir1
             |-script-dir2
              ..

I set denonvim.tag is lspconfig root_dir, I can't use deno.json because running a script automaticly creates a deno.lock which will have all dependencies of all the scripts which can clash

This used to work, but new versions of deno lsp server have a new feature that preloads all type/javascripts file in the workspace, so now if I open a script the lsp becomes really slow at starting because it have to read all my scripts

In the end I gave up and I just create a deno.json in the same script folder

I'll think about the shebang though , I'll look to what helix does, maybe I can pr such feature to nvim-lspconfig

[sigmaSd]

I added a pr for shebangs support neovim/nvim-lspconfig#2708

does that handle your use case ?

[johnpyp]

That's awesome! I'll try it out tonight. If it works how I think it would work then I think it's perfect.