You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
0 commit comments