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

[DanTup]

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

• [x] Detect when a folder has projects in sub-folders and prompt the user to add them
• [x] Allow the user to disable this functionality globally
• [x] Allow the user to say "Don't prompt for this folder"?
• [x] 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

[rrousselGit]

the users (not unreasonably) expected they could add a flutter launch config and set the cwd.

I'll admit I myself thought using cwd on a dart launch config would be enough for Dart-Code to know if this is a flutter project or not.
Is there any reason why this is not enough and we must use multi-root workspace instead ?

[DanTup]

Is there any reason why this is not enough and we must use multi-root workspace instead ?

There are many things that rely on us knowing where your project roots are (for example we need to know if your project is Flutter or Dart, we need to parse the .packages file, we need to be able to set sensible defaults in launch.json or in the case of flutter launch without it entirely). You also will want different launch configs for each project (different entry points, args, etc.) that make sense to live in the project folders. It's very hard for us to reliably guess this for all projects.

VS Code has great support for multiple folders being opened so it seems pointless trying to re-implement that ourselves (and we could never do it 100% accurately, whereas having the user define these project roots would always be reliable).

I think possibly Code could make working with repositories that contain multiple projects easier (for ex. support opening a folder as a workspace, which just behaves as if every immediate child was added as a workspace folder). I might raise a case about that, see if they'd consider it.

[DanTup]

I've opened https://github.com/Microsoft/vscode/issues/43902 to see whether MS would consider making it easier to open a folder as a workspace (which you could then File -> Save Workspace from if you wanted to persist or customise it).

[rrousselGit]

Also, how is analisis_options and other 'global' confs working with multi-root workspaces ?
Especially when you have only one of such file, at the root of your mono repo ?

[DanTup]

That's a good question I unfortunately don't know the answer to! When you have a multi-root project we basically send each of your roots to the analysis server (provided by the Dart SDK) so the behaviour is dictated by that.

@bwilkerson what happens here? I can't find any notes on it (I guess having multiple roots is somewhat specific to the server so not covered in these docs). If I send two analysis roots, does the server look for analysis_options.yaml in each and treat them individually or can there only be one for an analyzer instance? (also; will it walk up above an analysis root looking for one?)

[bwilkerson]

If I send two analysis roots, does the server look for analysis_options.yaml in each and treat them individually or can there only be one for an analyzer instance? (also; will it walk up above an analysis root looking for one?)

Each one is treated individually.

When server is given a list of analysis roots (directories), it creates a _context root_ associated with each one. It then traverses the sub-directories looking for .packages files (we will soon change this so that it also looks for an analysis options file, but it doesn't yet). When it finds a packages file, the containing directory becomes a new context root. At the end we have a collection of context roots.

For each context root, it looks in the root directory for a packages file and for an analysis options file. If either is missing, then that file is searched for in the parent directory on up the directory structure to the root of the file system (even if it's above the original analysis root).

By the end, each context root defines a set of files to be analyzed, a packages file to use to resolve package: URIs, and an analysis options file. The files within each context root (the ones that are not excluded or in a nested context root) are analyzed using the appropriate information.

[DanTup]

@bwilkerson Thanks! I presume the search up the tree is for each file individually (so an analysis_options.yaml file can be in a grandparent of the .packages one?).

If so, then @rrousselGit I think this will all just work as you would expect/like it to :-)

[bwilkerson]

I presume the search up the tree is for each file individually (so an analysis_options.yaml file can be in a grandparent of the .packages one?).

Correct. The two files used to configure analysis do not need to be in the same directory.

[DanTup]

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?

[bwilkerson]

In my opinion, server ought to just correctly handle nested packages, and there shouldn't be any need for its clients to scan sub-folders.

Flutter is a bit of a complication that we have not handled well as yet. The underlying analyzer code has the ability to use different SDKs for different code bases, but server currently only supports a single SDK. It really needs to minimally support both a Flutter and a non-Flutter SDK.

That said, if clients need to know whether a given file is in a Flutter package in order to correctly implement execution and debugging support, then we should consider adding an API to access that information.

[DanTup]

That said, if clients need to know whether a given file is in a Flutter package in order to correctly implement execution and debugging support, then we should consider adding an API to access that information.

There are some complications though.. For ex we need to know whether the project is flutter before we start up the server so we can start the right server (the one from dart in PATH or the one from the cache of flutter in PATH!

We do already have code that detects with a folder is a flutter project, it's just that we only run it for the project roots. We could definitely scan the entire tree (we actually kinda do this because of the packages folder issue) but there are drawbacks to doing it that way that the users don't seem to notice (they think it's just a debugger issue because that's usually the first place that shows an actual error).

For example:

1. If the user opens a parent folder and doesn't use multi-root then their launch configs will go at the parent level - so if someone just opens the child Flutter project directly, they won't see the launch configs. Same goes the other way around - if a user opens the Flutter project directly and adds launch configs and then someone else opens the parent, they won't see those
2. Same goes for settings; if a user wants different settings for each project (eg. preview-dart-2 on for a flutter project but not for a Dart project, or just on for one of their flutter projects) they can't do it unless each project is a root
3. Various commands currently operate at the workspace folder level (for ex. pub get). Unlike those above, we could change this so we maintain our own list of "project folders" but I don't know how reliable we could make it and it feels like we're starting to just re-implement another version of Code's workspaces

I'm kinda torn. I want to make it easy for the users so they don't have to have any special knowledge or read docs for things to work; but I also don't want to end up where it's not clear to users whether to use Code's workspaces or our "version" of them.

[bwilkerson]

For ex we need to know whether the project is flutter before we start up the server so we can start the right server (the one from dart in PATH or the one from the cache of flutter in PATH)!

I suppose we do today because it impacts which SDK analyzer will pick up. But if we can get that fixed (make server automatically pick up the right SDK on a per package basis), then it shouldn't matter which version of server you run.

I'm kinda torn.

Yeah, it's a hard problem.

If your users are only using VS Code for Dart development, then it might make sense to provide a custom experience that is optimized for Dart. But if your users are using it for other languages, or have prior experience with it, then it's probably better to conform to the expected UX.

In addition, if you have one usage pattern that you support, then you can often do a much better job of supporting it well than if you're trying to support multiple options.

It kind of sounds like it might be better, at least initially, to document the expected usage (I'm guessing that would be to open each package separately) and what the issues are when users do something different, and then make that one path work as well as possible.

For those that don't read docs, you might be able to detect when they're going off the beaten path and gently prod them back. For example, if you can detect when they're about to (or just have) open a directory containing multiple packages, perhaps a dialog suggesting that they open each package separately. Especially if you can offer to do that automatically for them.

[DanTup]

I suppose we do today because it impacts which SDK analyzer will pick up. But if we can get that fixed (make server automatically pick up the right SDK on a per package basis), then it shouldn't matter which version of server you run.

But with that changed, the analyzer is inside the SDK so how do we know which SDK's VM and snapshot to start initially?

Currently, I have 1.24 stable Dart on PATH but that's super-old for Flutter. If the user opens a folder and I want the analysis server to decide whether it's got Flutter projects, do I use the Dart SDK from path or the Flutter SDK from path?

you might be able to detect when they're going off the beaten path and gently prod them back

Yeah, that's kinda what this case was about. I think the VS Code multi-root thing is the best awy to go for now, so I'm hoping do try and detect if the user is doing flutter and maybe give them a prompt asking if they'd like to add the folder as a workspace root. I think it's still kinda weird to the user though if they open up ~/some_repo as the root and then end up with ~/some_repo/flutter_app as an additional root (it works fine, VS Code happily overlaps them, it just fields weird).

Another possibility is we scan the first level of folders and if we discover pubspec's we ask the user if they'd like to concert it to a multi-root workspace, and then add all of the folders as new roots and remove the parent folder (the disadvantage being anything not inside a folder is not visible, and creating new top-level folders then becomes tricky - oh, and when they close Code it'll ask if they want to save the workspace - but maybe that's not a bad thing). Possibly we could automatically add new folders too (though really we're then starting to implement https://github.com/Microsoft/vscode/issues/43902!)

[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.

[bwilkerson]

But with that changed, the analyzer is inside the SDK so how do we know which SDK's VM and snapshot to start initially?

If all of the latest versions of server automatically discovered the right sdk, then it wouldn't matter.

I propose we introduce a concept of "project folders" which are basically the folders in the workspace that are considered projects (basically have pubspecs).

Server does almost the same thing. We call them "context roots", and use .packages and analysis options files rather than pubspec files. My concern here is that DartCode and server will be doing slightly different things, which might lead to some behaviors that are confusing to the user.

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

Would this allow DartCode to handle opening both Flutter and non-Flutter packages at the same time?

[DanTup]

If all of the latest versions of server automatically discovered the right sdk, then it wouldn't matter.

I don't entirely follow. Let's say I have both Dart and Flutter in my PATH. From there we can find two Dart VMs. Which dart.exe and which analysis_sever.snapshot do we use? We can't ask the server which one without starting it?

Server does almost the same thing. We call them "context roots"
My concern here is that DartCode and server will be doing slightly different things, which might lead to some behaviors that are confusing to the user.

Yeah, that's valid. What sort of API do you have in mind - just exposing the context roots info, or something more fine-grained with request/response that lets us look up info about a particular file/folder?

I wonder if maybe I should go ahead with my plan (I don't think it's massive) to get a fix out there now (I think it's confusing people - I've seen so many people running flutter run from the embedded terminal and aren't sure whether they don't know about pressing F5, or they've had errors because of this and assumed it doesn't work) and then we can figure out how to move that to the server (I'd have a concrete list of everything using these "project folders").

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

Would this allow DartCode to handle opening both Flutter and non-Flutter packages at the same time?

We already support this via multi-root workspaces. If you open a multi-root workspace we basically look at each folder and figure out whether it's Dart, Flutter or Fuchsia. We assume Fuchsia is a superset of Flutter and Flutter is a superset or Dart and then we use the SDK/analyzer that we assume is able to run all of the projects (there are some flaws in this, like your Dart CLI app will run with the VM inside the Fuchsia/Flutter cache, but nobody has ever had any issues with it (multi-root projects with different project types are probably rare)).

[bwilkerson]

Which dart.exe and which analysis_sever.snapshot do we use?

It wouldn't matter which analysis server you started as long as you used the corresponding dart.exe to run it. The dart.exe used to run user code is a different question. But if the API we're discussing were to tell you which SDK was selected for each context root, then you wouldn't need to do any additional work to figure that out either.

What sort of API do you have in mind ...

Nothing concrete at the moment. I'm mostly exploring the space of possibilities to determine what would be best.

I wonder if maybe I should go ahead with my plan ... to get a fix out there now (I think it's confusing people ...)

That seems reasonable to me. I'm not sure when we'll have time to get the API defined and implemented, but it does seem like a better direction than asking clients to deal with all of the complexity.

[DanTup]

It wouldn't matter which analysis server you started as long as you used the corresponding dart.exe to run it.

I was previously under the impression that the version of the SDK that shipped inside Flutter was customised/patched on some way, and therefore we had to use it and not a standard one. However I now thing that actually that was more about making sure the one you had on your local machine matched the one in the engine being shipped over to the device? If so, then I think this is less of an issue than I thought. With a few outstanding questions:

1. If we started an old server, we'd be stuck with that servers API, even if there's a newer SDK for one of the projects? (we use the server version returned in the connected response to decide what APIs we can call)
2. How will the server find the correct SDK for say, flutter? eg. if there's no .packages file but there is a pubspec.yaml that says sdk: flutter, how does the server find it? (Dart Code looks on PATH and also at the user-provided config values)
3. If we start up and old server that doesn't support this new API, we're kinda stuck?

That seems reasonable to me. I'm not sure when we'll have time to get the API defined and implemented, but it does seem like a better direction than asking clients to deal with all of the complexity.

Yep, I agree! I'm hoping to look at it for v2.11 (likely shipping around the end of the month) so once it's complete I'll document all the things where I have this sort of logic and we can discuss.

Btw we actually already have a bunch of logic like this in debugger implementation, including parsing .packages so we can send the correct paths to the debugger - I'd love to offload this somewhere, but the debug adapter doesn't have access to the analyzer (it's in another process). Probably it's worth documenting this too so we can see if there's somewhere more appropriate than my debug adapter for it!

[bwilkerson]

I was previously under the impression that the version of the SDK that shipped inside Flutter was customised/patched on some way, and therefore we had to use it and not a standard one.

That's true. The Flutter SDK has a different set of dart: libraries than the web SDK. There's a lot of overlap, but each contains some libraries that aren't in the other.

If we started an old server, we'd be stuck with that servers API, even if there's a newer SDK for one of the projects?

Yes. I don't know how you find the SDK today. IntelliJ requires the user to configure it, which is kind of limiting. If you're auto-locating it/them, then you'd probably want to use the most recent of the possibilities to avoid that issue.

How will the server find the correct SDK for say, flutter?

Good question. It would need to look in the pubspec to determine which kind of SDK to look for, and I suspect we'd also end up looking on PATH for it.

If we start up and old server that doesn't support this new API, we're kinda stuck?

Unfortunately, yes.

[DanTup]

That's true. The Flutter SDK has a different set of dart: libraries than the web SDK. There's a lot of overlap, but each contains some libraries that aren't in the other.

Aha, that explains that then. In that case we need to do something to find the SDKs even if it's to pass them to the analyzer, otherwise it might end up with a Flutter project and not know where a Flutter SDK is?

Yes. I don't know how you find the SDK today. IntelliJ requires the user to configure it, which is kind of limiting. If you're auto-locating it/them, then you'd probably want to use the most recent of the possibilities to avoid that issue.

We support both. We search a bunch of locations (including path) and let the user specify in settings. We currently sort by userSpecified -> fuchsia flutter cache -> flutter cache for current project -> PATH -> flutter (from PATH) cache. I'm not sure if taking the newest one is an easy task, since we need to ensure we get the right type (can't use Dart (web) SDK for Flutter, for ex) and if there's a user-setting with prioritise that over anything else since the user picked it.

It's all a bit of a minefield :D

Good question. It would need to look in the pubspec to determine which kind of SDK to look for, and I suspect we'd also end up looking on PATH for it.

Then you might end up inheriting logic like this. For ex., if I've got the Flutter codebase open itself, I'd expect it prioritise its own local cache (line 92) over PATH.

[bwilkerson]

In that case we need to do something to find the SDKs even if it's to pass them to the analyzer, otherwise it might end up with a Flutter project and not know where a Flutter SDK is?

Server has a serious flaw right now, which is that clients have to provide an SDK on the command-line (I think it will use the SDK that it's embedded in of none is provided), but that means that it knows about one SDK and cannot correctly analyze both Flutter and non-Flutter packages in the same instance. That has to get fixed.

It's all a bit of a minefield ...

Sadly true. That's why I think we really need to do something to make it better. It's just a question of when.

Then you might end up inheriting logic like this.

Unless we can think of a cleaner way to compute the right SDK (which there might not be), yes. But it's better to have code like that in one place than in many places.

[DanTup]

Things to test across multiple projects folders:

• [ ] Package upgrades (should still run at workspace level)
• [ ] Detection of pub/flutter get needing running
• [ ] Automatic pub/flutter get (from prompt) run in correct folders
• [ ] Pub get from palette runs in correct folder (detected from active file)
• [ ] Pub get from palette runs (no active file) prompts with a good list of projects (and runs in correct folder)
• [ ] Flutter projects in sub-folders result in ProjectType == Flutter (daemon started, etc.)
• [ ] Launching debugger for flutter in sub-folders works
• [ ] Launching debugger for dart-cli in sub-folder works (cwd set to project folder)
• [ ] Workspace folders are always considered projects even if they don't contain .dart/pubspec (for compatibility - we may revisit this)
• [ ] Projects with packages folders containing projects work (eg. flutter - the workaround has gone)
• [ ] Debug config picks up correct project type based on active file (falling back to workspace)
• [ ] Test project folder picker UI

[DanTup]

Ok, I think I've ported all the workspace code over now such that it compiles and I can open a folder with a flutter projects in a sub-folder and it works (note: we only look a few levels deep for projects).

I'm gonna give it a good testing but suspect fairly soon I'll want some real testing before I'm confident in merging it (I've added a few tests, but general automated test coverage is quite poor right now - something I'm working on). If anyone is happy to give it a real world test for a few days when it's ready, I'd appreciate it!

[DanTup]

While testing, I found a bit of a major flaw.

Since we merged debug types in Code (to avoid prompting users about whether their project was Dart or Flutter) we now have to tell code which Debugger entry script to start (Dart or Flutter) when a session starts. The only information we get is the workspace root folder. This isn't enough to decide whether to use Dart or Flutter since we now may have both in the same folder.

I figured I could just use the "active script" since we use that elsewhere. Works great for some uses, but once you've created a launch.json for a Dart script, we then end up inferring Flutter if you have a script in the Flutter folder open, but using your Dart script as a launch arg.

I've raised https://github.com/Microsoft/vscode/issues/45220 asking if we the code that decides which entry point can be provided with the launch args, but I think this might be blocked in the meantime.

[DanTup]

I'm not sure I'm going to be able to deliver something great here, so I've raised a new request with VS Code to support having sub-folders as "WorkspaceFolders". I think it would be the perfect solution.

Please 👍 https://github.com/Microsoft/vscode/issues/45399!

[DanTup]

Based on discussions in https://github.com/Microsoft/vscode/issues/45399 I think I'm going to abort the work I was doing here (tracking my own definition of a project) and go back to the original plan of using WorkspaceFolders. But there will be two notable differences:

1. VS Code may gain a setting that lets you stop WorkspaceFolders that are already in your explorer from being duped at the top level - https://github.com/Microsoft/vscode/issues/45470
2. We'll make Dart Code detect when you open a folder with multiple projects and ask you if you'd like to convert it into a multi-root workspace. When you do this, we will automatically add all of the project folders (eg. anything with a pubspec) to the workspace and maybe also automatically enable the above setting (1) so they don't appear duped in the tree (they will appear only at their fs location, eg. as sub-folders).

I think these changes are reasonably simple (and somewhat achieve my original request with Code). For now I think with the new workspace API we can already do 2 (it just means you'll see the sub-folders also as top-level folders in the explorer) and that'll be fixed if/when MS do https://github.com/Microsoft/vscode/issues/45470 (please go 👍 it!).

If in future the analysis server gets the ability to help us out with which folders are projects, we can then use that info to pass on to Code to set the workspace folders. Feels like a much better solution (though may require some future tweaks from Code to make it feel completely seamless).

Any comments/questions/concerns, please shout!

[bwilkerson]

Do we have an issue to track / discuss the server requirements?

[DanTup]

@bwilkerson Don't think so, I've open https://github.com/dart-lang/sdk/issues/32485 and put some notes in there. Feel free to amend/add as required!

[DanTup]

@bwilkerson

but that means that it knows about one SDK and cannot correctly analyze both Flutter and non-Flutter packages in the same instance

Curiously, I just opened the Dart Code source code in VS Code and it now fires up the Dart extension because I have some embedded Dart/Flutter projects inside it (finally starting to build out the automated tests). It used to complain about the flutter one because of this issue; however I've noticed that since I ran flutter packages get(?) so that there's a .packages file, the errors have gone away. So at this point, the Flutter project is being analyzed correctly using the web SDK.

See this screenshot - the status bar (bottom right) shows that I'm using 1.24 of the SDK (!) yet I've got a dart:ui import with completion:

This is an old stable SDK. It makes me wonder how different the SDKs actually are, and whether it's all just in libraries? If dart:ui is only in Flutter, is seems like the web SDK can still find/load it via the package references?

(ofc, the package restore wouldn't work from the wrong SDK because there's not flutter command - but it might at least mean picking the right server is simpler - our assumption that we have to use a Flutter-shipped SDK VM/Analyzer snapshot if there are any Flutter projects might not be the case?).

[bwilkerson]

It makes me wonder how different the SDKs actually are, and whether it's all just in libraries?

The Flutter SDK is essentially built by applying a delta to the web SDK. The delta involves adding some libraries, such as dart:ui, and adding the flutter command-line app, and removing other dart: libraries, such as dart:html. So, mostly it's just a question of which libraries are available.

If dart:ui is only in Flutter, is seems like the web SDK can still find/load it via the package references?

I verified that the dart:ui library is _not_ in the web SDK.

However, the .packages file is only used when resolving package: URIs. The dart: libraries are resolved by looking in the file sdk/lib/_internal/sdk_library_metadata/lib/libraries.dart. That file contains information about where to find the source for each of the included libraries.

It's possible that you were actually using a Flutter SDK. I suppose it's also possible that flutter packages get does more than create a .packages file, but that seems unlikely.

... our assumption that we have to use a Flutter-shipped SDK VM/Analyzer snapshot if there are any Flutter projects might not be the case?

I apologize for the miscommunication. The VM and the analysis server snapshot are the same no matter which version of the SDK you're using. What matters is which SDK the analysis server will find when analyzing user code. The SDK can be specified on the server's command-line, but if it isn't then I believe it will default to the SDK from which the server is being run (that is, the SDK containing the VM being used to run the server).

[DanTup]

It's possible that you were actually using a Flutter SDK

I did some testing, and this doesn't seem to be the case. I'm running the SDK/server from a Web SDK and not passing any SDK info. It does seem like the analysis server is finding dart:ui as a result of the .packages file. If I remove it, things break - as soon as I put it back with references to the flutter repo like this:

flutter:file:///M:/Coding/Applications/flutter/packages/flutter/lib/

then it finds dart:ui again.

Here's a screenshot showing a single analyzer reading dart:html and dart:ui:

And here's the log (there are two analysis.updateContent calls at the top showing the content being sent, and then empty error lists further down). I'm not sure if this is good (it might be better than you thought) or bad (it's not behaving as expected)!

The SDK can be specified on the server's command-line, but if it isn't then I believe it will default to the SDK from which the server is being run

Gotcha, makes sense! So picking the newest analysis server is probably a safe bet if/when the server can pick the SDKs for each project reliably.

[bwilkerson]

Sigh.

I guess I was hoping / assuming that it had been "fixed" by now, but there's a bit of ugliness in Flutter that I'd forgotten about. For historic reasons I won't go into, a mechanism was introduced that allows analyzer to find dart: libraries that are specific to Flutter without having them mentioned in the Flutter SDK's libraries.dart file. That must be the mechanism that's kicking in here allowing analysis to be correct. In which case, yes, it's because analyzer is finding the flutter package in the .packages file.

The good news is that that will allow for correct analysis of Flutter code even when using a non-Flutter SDK. I'm not sure the opposite applies. (I'd have to look to see whether the Flutter SDK has the web-only libraries in it.) It's also fragile, should we remove this mechanism as I hope to be able to do eventually.

[DanTup]

Aha, thanks for the info. So far nobody has complained that they're doing mixed-projects and things don't work, so I'm going to leave it as things are (eg. always use Flutter SDK if any project is Flutter) and if people find it breaking, we can figure out the best fix then (which might be that the server handles it, or it might be that we have to spawn multiple analyzers, one for each "type" of project).

As for the original sub-folder issue here; I have a simpler fix but it's blocked by https://github.com/Microsoft/vscode/issues/45580. If MS will fix that (I consider it a bug, so hope they will this month). Hopefully that will address the immediate problem of people having flutter in sub-folders and it just not working.

[DanTup]

Ok, with https://github.com/Microsoft/vscode/issues/45580 fixed in Insiders, I think we finally have a reasonable solution to this (though for now you will see the folders as roots in explorer as well as in their normal places). We require Code 1.22 to merge this fix, however. I've asked about whether it could be included in the Feb recovery release but I'm not hopeful (it's not really critical to Code).

[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