nvim-lspconfig/lsp/tsgo.lua, branch v2.5.0[no description]http://git.sudomsg.com/mirror/nvim-lspconfig/atom/lsp/tsgo.lua?h=v2.5.02025-09-18T03:07:52ZRevert "add deno.lock root marker #4051"2025-09-18T03:07:52ZJustin M. Keyesjustinkz@gmail.com2025-09-18T03:04:59Zurn:sha1:78174f395e705de97d1329c18394831737d9a4b4
Reverts 33e318a3f0e729fb7ee82619a21172712b0ea288 (except for svelte).
fix #4074
close #4076
fix: ts/js LSPs require lockfile #40622025-09-11T03:31:23ZAlexis Tacnetalexis@mistral.ai2025-09-11T03:31:23Zurn:sha1:ec54d14e0ad816e4099738a2b8f8e61ed3c9430e
Problem:
Some projects don't have a lockfile.
Solution:
- Fallback to ".git" as a lower-priority root-marker (Nvim 0.11.3+).
- Fallback to CWD.feat(biome,eslint,svelte,ts_ls,tsgo,vtsls): add deno.lock root marker #40512025-09-03T12:21:40ZKai Moschcaukai@kmoschcau.de2025-09-03T12:21:40Zurn:sha1:33e318a3f0e729fb7ee82619a21172712b0ea288
Problem:
`deno.lock` is not recognized as a root marker in JavaScript related
servers.
Solution:
Add `deno.lock` as a root marker.fix(ts/js): support older Nvim 0.11.x2025-08-22T01:31:43ZJustin M. Keyesjustinkz@gmail.com2025-08-22T01:31:43Zurn:sha1:8373a1b7a7ab7a9972b55182073be5ac2f3bec0a
fix #4023
fix(ts/js): give lockfiles equal priority when finding root #40132025-08-20T16:31:19ZOskar Haarklou Veileborgohv1020@hotmail.com2025-08-20T16:31:19Zurn:sha1:99748c019f214d2f4372094fe5766a616f27e124fix: separate type annotation from `@brief` docstring #40172025-08-20T02:13:01ZIgor Lacerdaigorlfs@ufmg.br2025-08-20T02:13:01Zurn:sha1:5a49a97f9d3de5c39a2b18d583035285b3640cb0fix(ts_ls): server not starting if there is no typescript #40112025-08-19T15:25:52ZVinÃcius Weigert52323602+ViniWei@users.noreply.github.com2025-08-19T15:25:52Zurn:sha1:5f1c9a90c8db9c647da40ce6cf5be9e49ccbf0c7chore: miscellaneous type fixes2025-08-19T02:41:27ZIgorigorlfs@ufmg.br2025-08-19T02:41:27Zurn:sha1:ec27b247a5e25f6997b66aee30090eda18efaa27chore: add type annotation for configs2025-08-19T02:39:23ZIgorigorlfs@ufmg.br2025-08-19T02:39:23Zurn:sha1:030a72f0aa4d56f9e8ff67921e6e3ffd0e97bf07fix(ts/js): servers do not start when `bun.lock` exists #40082025-08-18T15:09:12ZMethapon200161303214+Methapon2001@users.noreply.github.com2025-08-18T15:09:12Zurn:sha1:34c9ecfdcc19d579f51c072300a71445fbec9da8feat(ts/js): improve monorepo support for Typescript, ESLint #39552025-08-17T21:12:42ZAlexis Tacnetalexis@mistral.ai2025-08-17T21:12:42Zurn:sha1:8ad2d8d8991d868ff8e7c21a7db624f32b882531
PROBLEM:
Monorepos (or "workspaces") in Typescript are more and more popular and
the associated tooling is evolving to improve the developer experience
in such setup. Especially, the `typescript-language-server` and the
`vscode-eslint-language-server` now supports monorepos, **removing the
need to spawn a different server for each package of a workspace**.
Example: with a few packages as the servers need to load every other
package to work (the `typescript-language-server`, even if spawned
multiple times with different `root_dir`, will load in memory other
packages to resolve the types), the amount of memory used grows
exponentially. But in fact, those servers support monorepos: they
support multiple configurations in subpackages and will load the correct
one to process a buffer. The ESLint server even supports loading
multiple ESLint binaries (and therefore versions), while keeping one
instance of the server.
SOLUTION:
Instead of only relying on the configuration files as `root_markers`,
discover the root of the package / monorepo by finding the Lock files
created by node package managers:
* `package-lock.json`: Npm
* `yarn.lock`: Yarn
* `pnpm-lock.yaml`: Pnpm
* `bun.lockb`: Bun
We still need to look at configuration files to enable the conditionnaly
attachment of the LSP for a buffer (for ESLint, we want to attach the
LSP only if there are ESLint configuration files) in case of LSP that
operates on files that are "generic" (like `typescript` or
`javascript`).
To do that, I replace the `root_markers` that were the configuration
files by a `root_dir` function that superseds them. It will both:
* look for a configuration file upward to check if the LSP needs to be attached
* look for the root of the "project" via the lock files to specify the `root_dir` of the LSP
PRIOR EXPERIMENTATIONS:
I've tried to play with the `reuse_client` quite a lot, trying to
understand if we need to spawn a new server or not looking at the
Typescript / ESLint binary that was loaded, but in fact it's way easier
to just have a better `root_dir` that is the true root of the project
for the LSP server: in case of those two servers, the root of the
package / monorepo.
I also tried to use the current directory opened as the `root_dir`, but
it's less powerful on nvim compared to VSCode as we navigate more inside
folders using terminal commands and then open vim.
I think this method also removes the need from a project-local config
(which could be quite useful anyway for ESLint flat config setting which
auto-detection is a bit unreliable / compute heavy) as this should work
normally accross all different setups.
Fixes #3910feat: tsgo #39892025-08-08T21:33:35Zskewb1kskewb1kunix@gmail.com2025-08-08T21:33:35Zurn:sha1:f65b426b6eddd5d9771322a03ec5167d7a765b9c