Build: Add "release" mode

[kevmoo]

See https://github.com/kevmoo/peanut.dart/pull/9

It seems common to need a build.release.yaml

• Specify dart2js + minify + trust flags
• Specify that you only want to build a target directory – web, etc

A lot of cleanup is required to turn an output from build into something you want to deploy.

• Delete dart files
• Move the packages directory under your target directory to build

Do we need a new top-level command?
Is a bool sufficient? Does it need to be plumbed through build?
What does Flutter need?

etc etc

[natebosch]

Need a "release" mode

We have previous discussed this and it's a bit tricky. We don't want build_runner to know anything about this so we need to support it as a general mechanism across Builders.

One possible solution we've discussed is understanding 'release' vs 'debug', ('dev'?) as a build_runner level concept without knowing specifically what it means, but letting Builders use that information how they want. Open questions are:

1. How would we surface this to Builders? Maybe as a special field on BuilderOptions?
2. How would we advice Builders to use it? For the case of build_web_compilers it might change the default compiler to Dart2Js, but how should it rectify that with manual config? For instance if I have an explicit build.yaml file that tells it to use DDC?
3. Is release/dev enough or do we need other modes?

Delete dart files

Hoping we'll get some mileage out of #1010 that might support this in a general way.

Move the packages directory under your target directory to build

Hoping #890 will solve this.

[jakemac53]

How would we surface this to Builders? Maybe as a special field on BuilderOptions?

Ya, add a field to BuilderOptions. This maps similarly to BarbackMode from transformer land.

How would we advice Builders to use it? For the case of build_web_compilers it might change the default compiler to Dart2Js, but how should it rectify that with manual config? For instance if I have an explicit build.yaml file that tells it to use DDC?

I guess its up to the Builder, but manual config should probably always win. The advice I think should be that you set you defaults based on the mode, and any config options override that.

Is release/dev enough or do we need other modes?

I think this is enough, technically barback supported custom modes but no Transformers ever used them afaik.

[natebosch]

Last time we had talked about this we also were thinking about whether build_runner needed this directly, or whether tools like webdev could be responsible for understanding these defaults and translating them to the right arguments like --define build_web_compilers|entrypoint=compiler=dart2js

[matanlurey]

I'd prefer punting this to webdev as well.

[jakemac53]

The disadvantage to punting it to webdev is it isn't a generic mechanism - it can only configure the builders it knows about - instead of allowing any builder to provide sane defaults.

Not a deal breaker necessarily - it can still provide value there.

[natebosch]

Discussed today. We want to give a way to have build.yaml files give builder options by mode. We _don't_ want the builders to be exposed to what mode it is, just the options with their defaults applied (then possibly overridden).

targets:
  $default:
    builders:
      some_dep|some_builder:
        options:
          always_applied_option: value
        release_options:
          only_applied_in_release_mode: value