| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: `experimental.useFlatConfig` forcefully turns on the logic to
use a separate programmatic interface for flat config usage in ESLint.
That interface was removed in ESLint v10 where flat config format is the
only supported config format. But when the setting is turned on the
language server still looks for that interface and fails when it can't
find it. The end result is that language server turns off it's
validation/diagnostics when used with ESLint v10.
Solution: do not turn on `experimental.useFlatConfig` setting based on
the presence of flat config files. Instead use the default behavior of
the language server which matches the ESLint's default behavior and let
the user explicitly override it via config when necessary.
|
| |
|
|
|
|
|
|
|
| |
Problem:
`checkhealth vim.lsp` reports the following warnings:
- ⚠️ WARNING Unknown filetype 'javascript.jsx'.
- ⚠️ WARNING Unknown filetype 'typescript.tsx'.
Solution:
Remove them.
|
| | |
|
| |
|
|
|
|
|
| |
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().
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
