I wonder if we can ask for this information from the Workspace, instead of copying this information for all folders. The thing is, there's one ScanKind per project, and that one instance is computed from the configuration. I've noticed that we also have a method that takes the greater ScanKind if we've different ones, but this isn't always true.

We already have the logic that computes ScanKind inside the find_project_root, we just need to expose it and we should be able to give it to the watcher on request.

There is a very slight duplication between the workspace and the watcher indeed, but I do think this is where it belongs. Note we don't copy this information for all folders, only for the watched folder, so in a typical setup we still store it only once per project.

I think however, that in order to address #6838, we may want to implement more granular watching and track it right here. But that's none of the workspace's business.

So the division as I see it is: the workspace determines what to watch, and the watcher is responsible for the actual watching.

but I do think this is where it belongs.

Can you explain why? IMHO, it's worth documenting. At the moment, I disagree, and if there's a specific reason to duplicate the information, let's at least explain it in a comment so we don't lose the insight.

Can you explain why you disagree? I just spent three paragraphs explaining my reasoning, so I'm unsure which part you're disagreeing with.

Can you explain why you disagree? I just spent three paragraphs explaining my reasoning, so I'm unsure which part you're disagreeing with.

When the configuration changes, and the ScanKind is downgraded from Project to KnownFiles, the LSP picks the change via the LSP file watcher, and the project is scanned again using the KnownFiles. Now the watcher has its copy of ScanKind, and we do run the heuristic, it keeps using Project, based on what's written here: https://github.com/arendjr/biome/blob/f50fe78ca28acd434be858e55766604fdacae72e/crates/biome_service/src/workspace_watcher.rs#L241-L243

There are some inconsistencies, and that's why I think there should be one single source of truth.

Now, I don't have enough knowledge of the watcher, so I don't understand technical details such as "we may want to implement more granular watching and track it right here".

So, I still have my doubts about the logic, but unfortunately, I don't have enough technical knowledge to understand everything. So don't feel blocked by my comment. However, if the new logic addresses my concern, feel free to resolve my comment.

It's a fair concern, but I think the solution is simple: if the ScanKind changes, the workspace should tell the watcher about it.

Now the watcher has its copy of ScanKind, and we do run the heuristic, it keeps using Project, based on what's written here: https://github.com/arendjr/biome/blob/f50fe78ca28acd434be858e55766604fdacae72e/crates/biome_service/src/workspace_watcher.rs#L241-L243

I think this may be slightly misinterpreted. The doc was meant to indicate that if a single watcher notification is received from the OS that contains paths that belong to different projects with different scan kind configurations, only then do we assume to use a single scan kind for both. It's a highly unlikely possibility, but we play it safe in such a case.

Btw, I think we overlooked something with #6839, which is that when we call update_service_data(), we should've already checked whether the file was ignored or not. So it seems we're trying to put the is_ignored_by_scanner() check too deep, which is also giving an issue with this PR, since the ScanKind is no longer available at that point. I will resolve that here as well.

I have moved the calls to is_ignored_by_scanner() to the watcher itself. This should not have any other effect except to avoid redundant calls done by the scanner itself, and all the tests are still green. I added a test case too. But just in case, maybe you want to re-test on your end as well.