📎 LSP: support for Workspaces about biome HOT 11 CLOSED

I'm adding a $50 bounty to this ticket. I absolutely adore Biome, but this thing is affecting my workflow very much and it's the only thing preventing me from using Biome in many, many repositories.

Bounty will be granted, via GitHub Sponsors, to whoever makes Biome's linting and formatting experience in VSCode on par with ESLint/Prettier, i.e. fully respecting biome.json files at the roots of multi root workspaces, as well lower down the tree.

from biome.

Thanks for the detailed explanations. 🍻

But I think what you said in this topic is not about multi-root workspaces, but multiple projects (or package manager workspaces) in a single-root LSP workspace. That should fall into the category of monorepo support which can be discussed in #2228.

I'm talking about multi-root workspaces, not monorepo. i.e. in VS Code, it's the folders in the xxx.code-workspace file.

I concur that one LSP server with multiple LSP workspace instances is the way to go. Each root/workspace should have their own biome.json and each LSP workspace instance should be isolated from each other.

from biome.

The PR that implemented the feature is in main, the next release will have this feature. We will update the documentation once we are close to the release.

from biome.

You can test LSP workspaces using this nightly: https://github.com/biomejs/biome/releases/tag/cli%2Fv1.7.4-nightly.125f34b

from biome.

Hi, I'm not sure how other client work so don't know if that is correct, but does other clients has the same workspace concept as in VSCode? Bigger IDE such as Visual Studio or IntelliJ has similar concepts, don't know if neovim, sublime, etc. has similar things or not.

I don't think it is about "fairness". It's about complexity and separation of concerns. The workspace in VSCode can be different in Visual Studio IntelliJ, neovim, etc. So adding the support on the server side might make it more complicate than necessary.

Another consideration is performance and distribution. If the workspace consist of projects/repos with very different sizes, some extra large and some are tiny, is one LSP instance the best approach or it is better to separate them so that one will not brought down the others? How about during file rename or bulk change? On vscode, doing a find and replace on hundreds of files brought it to a halt by the Prettier extension. Biome extension also have that problem but it is a bit better.

Just want to bring these points up so that you can drive the design towards a good direction.

from biome.

Adding my two cents here.

The projects within a workspace (vscode workspace) can be owned by different teams and they have different configuration.
Also the file/folder structure can be very different (thus the files.include and files.ignore).

So switching setting on the fly before handing a file may not be the best approach.

It might be better if there can be one instance of LSP per project and the vscode extension talks to these instances.

from biome.

@unional

but does other clients has the same workspace concept as in VSCode? Bigger IDE such as Visual Studio or IntelliJ has similar concepts, don't know if neovim, sublime, etc. has similar things or not.

Yes the workspace is a concept of the Language Server Protocol (LSP), so it will be supported in any editor that follows and implements the spec. It's not a VSCode-specific thing.

Another consideration is performance and distribution. If the workspace consist of projects/repos with very different sizes, some extra large and some are tiny, is one LSP instance the best approach or it is better to separate them so that one will not brought down the others?

From the VSCode Wiki, single language server is the recommended way to implement the multi-root workspaces support:

Single language server or server per folder?

The first decision the author of a language server must make is whether a single server can handle all the folders in a multi-root folder setup, or whether you want to run a server per root folder. Using a single server is the recommended way. Sharing a single server is more resource-friendly than running multiple servers.

But I think what you said in this topic is not about multi-root workspaces, but multiple projects (or package manager workspaces) in a single-root LSP workspace. That should fall into the category of monorepo support which can be discussed in #2228.

is one LSP instance the best approach or it is better to separate them so that one will not brought down the others?

I think one LSP server instance doesn't necessarily mean one will bring down the others. We can preserve an internal structure where one LSP server has more than one LSP workspace instances, and each workspace instance can also have more than one projects. And on each editor fileOpen/fileChange event, we will decide the project or workspace the file belongs, and apply the settings accordingly. In this way, biome configurations can also be set in a project-level. With a proper cache strategy, this shouldn't be a problem.

The reason why Biome needs to understand things in a workspace-level instead of just a project-level is answered in #2228 (comment). Actually, we already have module resolution involved in the extends field of the configuration, and it wouldn't be possible to extend the configuration from another package in the same workspace in a monorepo setup if Biome cannot do workspace-level analysis.

Just to be clear, the "project" I mentioned above is a one-to-one correspondence with the "package.json" files. And I think its a reasonable minmal granularity for the Biome configuration.

from biome.

Thank you, @wojtekmaj. Would you consider funding the issue via Polar instead? We added a badge to the issue now.

from biome.

You're suggesting a solution at the client level (VSCode), not the server level (LSP). I don't think that's what we want to do, because other clients (neovim, sublime, etc.) would not benefit from it, and it's not fair to favour only VSCode.

So switching setting on the fly before handing a file may not be the best approach.

I'm not sure. The configurations can be computed when workspace/workspaceFolders is called; then, we just need to swap the configuration when the workspace folder changes; the LSP will signal this with workspace/didChangeWorkspaceFolders.

from biome.

Hi all,

Adding my simple use case here (I do not understand deeply LSP, sorry if I does not bring something useful, I'm a simple user)

I believe I'm facing a related issue here.

I got a team workspace like the following

a-project
- eslint.json
b-project
- biome.json

Currently in the b-project, everything is fine related to biome using CLI. However, the configuration is not applied on the b-project with the vscode extension, and it is not usable at all. After some tests it appears that the "workspace root folder" here is the a-project (alphabetically ordered ?).

As I workaround, I copy/paste biome.json in the a-project, and then the vscode extension is happy and apply my rules (having to pay attention to not commit this file)

In order to have a better alternative, would it be a good idea to define the source biome.json path in the extension settings ? (could also be a profile/workspace setting making it usable in different workspace as well, defaulted to the root one so behave normally if not set).

PS: eslint does not have this strange behaviour

Thanks

from biome.

I accessed here from a link in the official documentation. Is the support already finished? If so, I want to update the documentation. If it has not been addressed, it may be a good to reopen this issue or make the link to another issue.

from biome.