nvim-lspconfig/lsp/vtsls.lua, branch v2.5.0

Revert "add deno.lock root marker #4051"

2025-09-18T03:07:52Z

Reverts 33e318a3f0e729fb7ee82619a21172712b0ea288 (except for svelte). fix #4074 close #4076

fix: ts/js LSPs require lockfile #4062

2025-09-11T03:31:23Z

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 #4051

2025-09-03T12:21:40Z

Problem: `deno.lock` is not recognized as a root marker in JavaScript related servers. Solution: Add `deno.lock` as a root marker.

fix(vtsls): inform the LS its client is neovim #4048

2025-08-31T17:34:55Z

fix(ts/js): support older Nvim 0.11.x

2025-08-22T01:31:43Z

fix #4023

fix(ts/js): give lockfiles equal priority when finding root #4013

2025-08-20T16:31:19Z

fix(ts_ls): server not starting if there is no typescript #4011

2025-08-19T15:25:52Z

chore: miscellaneous type fixes

2025-08-19T02:41:27Z

chore: add type annotation for configs

2025-08-19T02:39:23Z

fix: vtsls does not start in monorepo with `bun.lock` #4007

2025-08-18T03:25:07Z

feat(ts/js): improve monorepo support for Typescript, ESLint #3955

2025-08-17T21:12:42Z

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 #3910

fix(vue_ls): support `vue_ls` v3 #3943

2025-07-10T13:14:43Z

Problem: `vue_ls` made breaking changes to its config in v3. Solution: Change the typescript language server for `vue_ls` from `ts_ls` to `vtsls`. Add a client handler to communicate between `vue_ls` and `vtsls`. Remove `typescript.tsdk` option. Remove documentation for the deprecated takeover mode.

docs: cleanup

2025-04-18T15:44:38Z

- brief should live at the top of each file - fix indentation for some docs

fix(docs): docgen.lua reads from `lua/*.lua` #3708

2025-04-13T02:40:01Z

Problem: Since configs now live in `lsp/`, the docgen needs to be updated. Solution: Read the configs from `lsp/`. Parse the `@brief` docstring to get the docs.

feat: migrate to vim.lsp.config #3659

2025-04-12T22:15:43Z

Problem: Nvim 0.11 has vim.lsp.config, which mostly replaces the legacy nvim-lspconfig "framework". Solution: Migrate all configs to `lsp/*` variants. The old configs in `lua/lspconfig/` are "frozen". The new configs include these changes: - `commands` field became raw calls to `vim.api.nvim_buf_create_user_command` inside `on_attach`. - `root_dir` became: - `root_markers` whenever the file list was simple didn't need to mach `*` - if the logic was complicated, or needed to match something like '\*.c', it was defined as a vim.lsp.Config `root_dir` callback. - `on_config_change` became `before_init`. I don't actually know if this is the correct approach, but looking around the documentation of `nvim-lspconfig` a saw that it was defined as the function that gets called as soon as the config have `root_dir`, and so I thought `before_init` might be the closest alternative. - `docs.description` became a luadoc `@brief` docstring. - `single_file_support = false`? Co-authored-by: Aliou Diallo Co-authored-by: Justin M. Keyes