Jonas Finnemann Jensen

I see no good solution. In hindsight, this is probably a good reason to not add support for `pubspec_overrides.yaml`. It seems to me that options could be: * update `pubspec.lock`...

I could imagine something like: ```yaml # in pubspec.yaml config: : : # Example configuration for package:retry retry: default_retries: 5 ``` Then in `package_config.json`: ```js { "configVersion": 2, "packages": [...

> Conditional imports would continue to be supported only for dart.library.x expressions Oh, that makes me sad. We could supposedly change that some day, but I understand of there is...

@dcharkes I was surprised that you wanted configuration from other sources than the root-package. For replacing top-level config files like `..._options.yaml`, it'd only really make sense to consider the root-package....

> The latter could be put in, say, `lib/cfg/localization.json` of each package that wants to tell `package:localization` something, then the tool from `package:localization` can read the `package_config.json` to find all...

> But I can use `dart pub deps --json` for the time being. I think that's a good way to get started. We can always improve performance by: * (A)...

Just doing `--only=production` would be fine for now. It doesn't matter that this is a complicated flag, as it's mostly used in scripts and very specific options.

> For production actually I think it would be more likely you need your dev_dependencies? For instance you shouldn't really be shipping your actual app code under lib - that...

> That would make sense - except that bin/ is actually a public directory and those executables are exposed via `pub run` to all downstream users.... If my package is...

Hmm, `--only=dependencies` could also do the trick.. or `--exclude=dev_dependencies` If we want to be obvious :) Note. yarn does `--production=true|false`.