Handle flutter projects in sub-folders better (req: Code 1.22)

Originally we had a request to support Flutter in sub-folders (#385) but with VS Code multi-root support we kinda avoided it. It came up again today via @timsneath.

I think the way it’s implemented now works well - I think having Code (and therefore Dart Code) explicitly understand where the project roots is is better than us trying to infer this from scanning the folder. However, it does seem like it’s hard for a user to discover this - the default thing is for people to just open the root of their repo which may have many projects.

At a minimum we should have some better docs on how to structure things (tbh, the whole README needs overhauling) but ideally we should also detect when a user appears to be trying to do Flutter stuff if it’s not set up this way and give them some pointers. In both cases where this came up, the users (not unreasonably) expected they could add a flutter launch config and set the cwd.

Edit:

In next VS Code we have the ability to add new folders to the workspace programatically. Maybe if we think the user has flutter in sub-folders (or tries to launch them) we can prompt them to add them as folders and do it for them?

Edit 2: Plan

• Detect when a folder has projects in sub-folders and prompt the user to add them
• Allow the user to disable this functionality globally
• Allow the user to say “Don’t prompt for this folder”?
• Make sure debugging works
• Set setting to hide them from top level (requires https://github.com/Microsoft/vscode/issues/45470)
• Consider doing the update silently

[lukepighetti]

So far nobody has complained that they're doing mixed-projects and things don't work hate to be that guy but here I am! 😄 @DanTup https://github.com/Dart-Code/Dart-Code/issues/1248

[DanTup]

Ok, I’ve been convinced in https://github.com/Dart-Code/Dart-Code/issues/637#issuecomment-370012828 that we need to actually support these nested projects. There’s a convention for putting example code into an example folder and it certainly doesn’t feel like you should need to promote that to a root to run/test it.

I propose we introduce a concept of “project folders” which are basically the folders in the workspace that are considered projects (basically have pubspecs). We will use this list in place of workspace folders (including a custom version of getWorkspaceFolder(Uri) to use them). We won’t however try to reproduce any VS Code functionality that exists for multi-roots however.

So, things we probably need to change:

• Startup code needs to walk down the tree (at least a few levels) looking for pubspecs to see if they reference flutter when deciding on the project type
• getDartWorkspaceFolders needs changing to be getDartProjectFolders and return all folders containing pubspecs (if a workspace folder contains 0 pubspecs we should probably add it as a project, but otherwise not)
• Any commands using the built-in workspace picker should instead use a custom picker list (this may already be done)
• Any code using isFlutterProject needs reviewing to work from the nearest parent “project folder” instead of the workspace folder
• Debugger should base cwd off the nearest “project folder”

Note: There will still be drawbacks to working this way - for ex. you can’t configure a launch.json or any settings for your example folder; it will instead have to go in the folder you open - and this means if someone copy/pastes your example folder it may behave differently. However, the user is still free to add example as a project root and give it these settings.