| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
biome/eslint/ts_ls/tsgo/vtsls #4203
Even though Deno docs says that both deno.json and deno.jsonc files can
be used for its configuration, deno.jsonc was not being considered to
prevent biome/eslint/ts_ls/tsgo/vtsls to run in Deno projects.
|
| | |
|
| | |
|
| |
|
|
|
| |
Close https://github.com/neovim/nvim-lspconfig/issues/4129
Since cwd is a necessity for many JavaScript project (see discussions in https://github.com/neovim/nvim-lspconfig/issues/4015), this fix takes an alternative approach to manually exclude Deno projects from biome/eslint/ts_ls/tsgo/vtsls 's `root_dir` detection logic. There is no need to change svelte since it has a different filetype.
|
| |
|
|
|
|
|
| |
Reverts 33e318a3f0e729fb7ee82619a21172712b0ea288 (except for svelte).
fix #4074
close #4076
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Problem:
`deno.lock` is not recognized as a root marker in JavaScript related
servers.
Solution:
Add `deno.lock` as a root marker.
|
| |
|
|
| |
fix #4023
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
| |
Problem:
:LspEslintFixAll command is no longer synchronous with the new
`vim.lsp.config` config, so the file is written without the applied fixes.
Solution:
Use request_sync('workspace/executeCommand') instead of client:exec_cmd().
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
