fix: improve typescript server path search for ts dependents lsp

[fuegoio]

LSPs like volar (for VueJS), astro or mdx_analyzer rely on a path for the Typescript server they should use. But this path is wrongly assumed to be inside node_modules/typescript/lib starting from the nearest package.json file.

In fact, in case of monorepos / workspaces, with all package managers like npm, yarn or pnpm, some hoisting can take place. This means that the typescript node module will get move higher up in the tree to be shared between all projects and avoid duplication. The NodeJS module resolution works like this, by trying to find the module upward in the tree, one directory after another.

Therefore, it can happen a case like this:

monorepo-root
 - apps
 > - app-number-one
 >> - node_modules (without typescript)
 >> - package.json
 > - app-number-two
 >> - node_modules (without typescript)
 >> - package.json
 - node_modules (with typescript)
 > - typescript
 - package.json

I therefore adapted the Lua algorithm to match the one of NodeJS (and the one of the ts_ls server, that does it natively).

Even if some LSPs like volar going towards "hybrid modes" where they don't need to spawn their full TS server (because usually users will spawn it nevertheless for other projects), this is still required and needs to be correctly setup to work on the files they target.

I've also mutualized this logic at one place to avoid de-duplication, but feel free to correct me on that. I've created a simple typescript.lua file, imagining that we could have language specific utils for LSPs that need it.

[fuegoio]

Seeing from the CI that I should maybe not update the legacies LSP configs, but I understood they were still used in older versions of Nvim. Feel free to tell me what I should update or not.

[justinmk]

cc @Grahf0085

but I understood they were still used in older versions of Nvim

well, they're frozen. anyone on an older version can either upgrade or use the old configs.

[justinmk]

would neovim/neovim#33485 address your use-case here?

[fuegoio]

cc @Grahf0085

but I understood they were still used in older versions of Nvim

well, they're frozen. anyone on an older version can either upgrade or use the old configs.

So I don't update them, even for fixes like this that could benefit from a backporting? I'm myself not yet using the new config as my config is a bit messy and I have yet to understand how to change my setup to enable ahah.

would neovim/neovim#33485 address your use-case here?

Unfortunately the root marker is different from this as here we could have a root that is successfully determined as app-number-one if for example this project has Vue or Astro installed (main requirement for the LSP to work), but the TS server could still be up one level or two.

Honestly LSPs should be in charge of doing that instead but I guess they want to allow flexibility on instanciation.

[justinmk]

So I don't update them, even for fixes like this that could benefit from a backporting?

can make an exception in this case.

[fuegoio]

can make an exception in this case.

Nice thanks! Normally good on my side then :)