Supporting use cases where the monorepo root is opened as a single workspace in VSCode

[fronterior]

Hello,

I created an unofficial Biome plugin called Biome Monorepo to support this use case.

This plugin supports correct linting and formatting with the appropriate biome.json configuration in subprojects that use Biome, even when opening a monorepo root as a single workspace in VSCode. I’m not sure if support for this use case is on the official plugin roadmap, but I thought it might be helpful if it is considered, so I wanted to share our experience.

Our team manages multiple projects in a monorepo using ESLint + Prettier. Since Biome’s performance is impressive, we decided to migrate to Biome. The challenge, however, was that there were too many files that could not be fixed with autofix. Some of these rules were critical, so we couldn’t simply downgrade them to warnings and proceed with a full migration. It was unclear when we would ever finish the migration for the entire codebase.

We therefore had to migrate project by project. The reason I built this plugin is because most of our team members use the monorepo root as a single workspace in VSCode. As noted in some existing issues, the current biome-vscode plugin does not properly recognize subproject biome.json configurations when only the monorepo root is opened. It ends up using the root biome.json or falling back to defaults, and even runs checks on projects that don’t use Biome. Opening every project as a separate workspace solves this, but for us, keeping the monorepo structure visible in VSCode is more convenient, so we wanted to preserve this workflow.

The official Biome plugin also has features our team doesn’t really need, and I expected that proposing changes would take a long time. So I decided to create a plugin focused solely on our use case. The goals were:

• Identify projects that actually depend on Biome by checking package.json, so that only those are linted/checked (to support incremental migration).
• Map each project to its own Biome binary, since different projects may use different Biome versions, and spin up as many LanguageServers as needed.

I referenced the source code of this plugin quite a lot during development. At first, I thought it would be enough to filter the documentSelector in the LanguageClient to include only projects using Biome, but that wasn’t sufficient. While it prevented checks from running on non-Biome projects, the binaries still failed to find the correct biome.json per project.

Looking into Biome LSP, I found that read_config resolves the biome.json by searching upward from VSCode’s working directory. So, if the LSP could be given the subproject path as its workspace folder intentionally, it would then pick up the right configuration even from the monorepo root.

My implementation overrides fillInitializeParams in the LanguageClient and reassigns the workspaceFolders field with the subproject paths. This seems to be working as intended. For now, I plan to keep maintaining this repository and also bring in some useful features from the official plugin (like temporary file handling on Windows, Yarn PnP support).

A potential concern is that the plugin searches through all package.json files in the monorepo to check for the biomejs dependency, which means initialization time will increase as the monorepo grows larger. This could be addressed in the future by adding caching, or by introducing an initialization-related option such as workingDirectories.

I’m sharing this in case it might be helpful for others working in similar monorepo environments. If there’s interest in including this functionality in the official plugin, I’d be more than happy to contribute. Please feel free to reach out if you have any questions.