| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Problem:
Biome server becomes active if biome appears as a substring in
package.json, even when biome is not being used.
Solution:
Since biome is behind the `@biomejs` namespace we can narrow its
activation by appending `js` in the searched term.
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The biome [documentation](https://biomejs.dev/guides/big-projects/#use-multiple-configuration-files) mentions that
> When you use Biome’s features - either with the CLI or LSP - the tool looks for the nearest configuration file using the current working directory.
>
> If Biome doesn’t find the configuration file there, it starts traversing upwards the directories of the file system, until it finds one.
I think it makes sense to follow this recommendation, so we can have proper monorepo support. Currently, in a monorepo, a new client is started for each `biome.json` (similar situation as #3910), which is unnecessary, since biome supports monorepos [natively](https://biomejs.dev/guides/big-projects/#monorepo) (as of v2). The alternatives I have considered aren't as robust.
The first concern is searching for a `biome.json` to be set as the root. Unfortunately, that's cumbersome: the documentation recommends flagging the files that _aren't_ the root. That means we _can't_ use `root_markers_with_field` to search for a file that **is** the root. The proposed solution solves this issue by behaving as the CLI would.
Secondly, we have to check if a project uses biome, via `package.json` and friends, which is the fallback behavior. I've considered using #3955's approach of lock files, but since it would require searching for the field 'biome' within lock files (which are often thousands of lines long), I was worried about causing a performance hiccup.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The latest release of biome adds prelimanary support for formatting html
files https://biomejs.dev/blog/biome-v2/#html-formatter
Thus, html should be added to the list of filetypes for the biome LSP.
|
| |
|
|
|
| |
- brief should live at the top of each file
- fix indentation for some docs
|
| | |
|
| |
|
| |
This reverts commit cd54cca6c4a03b89f2a82e32ae6bfc230b5b4193.
|
| |
|
