Add a flag to pubspec to signify dependencies are managed externally and "pub get" should not do anything

[DanTup]

The Dart SDK dependencies are managed via DEPS and running pub get inside one of the packages results in an additional .dart_tool/package_config.json being created that references packages from Pub (instead of the version written by the SDK tooling into the root). This results in broken packages with spurious errors and it's not always obvious what the cause or fix is (it's usually to delete a .dart_tool folder from inside the pkg that's broken).

For some functionality (such as using the test runner in VS Code), commands like dart test are used, which may trigger an implicit pub get. To avoid this, Dart-Code detects the SDK and disables automatic pub get and all of the test runner functionality. There have been requests to support this (and it's something I miss myself). There are ways to make this work with dependency_overrides, but it means additional work and it still results in superfluous package_configs that could lead to confusion.

I wonder if we could have some kind of flag in pubspec (which could be added to all of the SDK's pkg/*/pubspec.yaml files to signify that packages are managed externally, and will prevent dart test (or even pub get) from fetching packages or creating new package_config.jsons:

name: dds
version: 2.9.4
deps: external    # something like this (we can't call it dependencies :) )

This flag should only be used to suppress fetching/resolving packages and creating package_config.jsons and shouldn't impact anything else (for example pub publish for SDK packages should continue to work as they currently do).

@jonasfj @sigurdm

[sigurdm]

I like the general idea. This would also improve support for other mono-repos.

I think there was an idea floating around for marking the dependencies external by something like:

name: foo
version: ....
use_package_config: ../../

[DanTup]

use_package_config: ../../

I was going to suggest that too, but I wondered if someone put some arbitrary path there there might be issues if some tooling still just looked up the tree and gave inconsistent results. With a simple flag, the rules for which package_config.json to use don't change.

Either of them should help repos like the SDK though :-)

[sigurdm]

I have written a proposal-issue (that is basically this idea in more words) and closing this issue in favour of that.

#4022

Please add any comments you have there!