Detect projects for open files even if they're outside of the projectSearchDepth limit

Describe the bug When working in a mono repo that has packages that support different platforms (Ex: package A supports iOS and Android and package B support iOS, Android, Web) the incorrect device options are shown. When package_b/example/main.dart is opened, the device drop down shows “enable web for this project” even though web is enabled for the project. Running flutter run -d chrome from the same dir works just fine.

To Reproduce Steps to reproduce the behavior:

1. Create a mono repo with multiple packages with varying platform support
2. Observe what device options show in the devices drop down

Expected behavior The available devices should reflect what devices are available for the currently opened file.

Screenshots If applicable, add screenshots to help explain your problem.

Versions (please complete the following information):

• VS Code version: 1.64.2
• Dart extension version: v3.36.0
• Dart/Flutter SDK version: flutter 2.10.03

[DanTup]

I’ve pushed some changes via #3974 that includes increasing the search default to 5 levels. Now, if the project search takes too long, a notification will appear (“Searching for projects…”) and can be cancelled (which will just use the results found so far).

I think that fix probably removes the need for this, so will close it - but we can re-open if it turns out 5 levels is also not enough.

[DanTup]

Thanks for confirming!

Anyway, if possible the default should be higher than 3 IMO.

There’s a bit of a trade-off here. If we set the value high, then every project opened can take longer to search the tree looking for projects (not just during open, but every time the extension needs an updated list of projects - such as opening the device selector or running tasks). Sometimes people open very large folders (like their entire home directory, or with non-Flutter projects with node_modules in the workspace) and have reported slow performance from these searches. If there’s an average of 10 items per folder, the difference between searching 3 levels and 5 levels could be 10^5 (100,000) instead of 10^3 (1,000) calls to the filesystem.

I previously tried switching to VS Code’s own APIs for finding pubspec.yamls in the workspace, but it turned out to be slower than the custom walking code we have today.

I think a possible fix for at least some of these cases is to ensure projects for any open file are always locating during the search. It won’t cover all cases (eg. if you close every file then open the device selector), but it should cover those most likely to occur (and we can cache these projects in a list to include in all subsequent searches for the session), and the setting is still there (which could be committed into .vscode/settings.json into a monorepo project) where that isn’t sufficient.

I will see if I can come up with something better that will cover all cases without just slowing down every search in a large folder though.