Danny Tuppeny

> Correct, but in this case the developer would be deliberately conscious that his/her global context But this isn't "global context", this is context from "one of the other projects...

> Or, you could leave things as they are, with a `.dart_tool/package_config.json` per project. Instead, Dev Tools could have a setting where you specify which `build.yaml` (and `dependency_override` section) rules...

If you copy your `pubspecs`/`dependency_overrides` into the new workspace so that the layout is similar, can you reproduce it? If not, if you completely duplicate your workspace, does it repro...

Thanks - if you're able to get to a repro you can share, that would help _a lot_. It'll be difficult for me to do without a project that triggers...

> It looks good, doesn't it? Nevertheless, import 'package:flutter/material.dart'; in the main.dart file is underlined with a red color Yes, if that `.dart_tool/package_config.json` was in the new project then it...

Yeah, that makes sense since probably the project is created and then `flutter pub get` is run to write the `package_config`. The analyzer _should_ handle this correctly though (and it...

Yeah, `flutter create` will do both. But the analyzer is just watching the disk, so it'll see the `pubspec.yaml` file created and then start building an analysis context for it,...

From a quick glance at this, I think it could be the issue I discussed in https://github.com/dart-lang/sdk/issues/55268#issuecomment-2084925837 where we were reusing some cached information that we should not when resolving...

I was wrong in my comment above, the fix actually was already in the previous beta when I wrote it. So if you're able to test with the current Flutter...

I can reproduce this. I think the problem is that line 130 does not contain a valid location to stop (for example if you put a breakpoint on line 128...