| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
The current biome project root logic uses JS package manager
lockfiles to get the project root in mono repos.
If one is not using any JS (wasm) and raw CSS, that doesn't work out.
In those cases, only a biome.json exists as a marker on where the
frontend's project root inside the mono repo may be located.
|
| | |
|
| |
|
| |
PR #4130 prevents a bunch of lsps to start in a deno project, including biome. However I think the biome lsp should indeed be active in deno projects with a `biome.json`.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
