[hooks] Expose `flavor`

[HosseinYousefi]

Flutter applications can have different flavors like: staging/prod, or free/premium: https://docs.flutter.dev/deployment/flavors

It also supports conditionally bundling assets based on the specified flavor. We should support the same by exposing the flavor in the hooks.

@dcharkes

[dcharkes]

And flavor can influence what assets are build?

• Then it must be part of the HookConfig and introduce a different build directory.
  • Most likely we then want to address [native_assets_cli] Sharing work between build hooks #1379 first, so that you don't end up duplicating all the work always.

Flavor is a single string argument?

[mkustermann]

Flutter applications can have different flavors like: staging/prod, or free/premium:
...
Then it must be part of the HookConfig and introduce a different build directory.

If "flavors" are a flutter specific concept then we may not want to make it part of the core build/link infrastructure. A great opportunity to start modularizing the build infrastructure!

flutter build / flutter run could provide a extension to the build/link APIs e.g. via extension methods on BuildConfig that expose a FlutterBuildConfig object.

[dcharkes]

A great opportunity to start modularizing the build infrastructure!

I can see the argument of why we not only want to make the asset types extensible. 🤓

If "flavors" are a flutter specific concept then we may not want to make it part of the core build/link infrastructure. A great opportunity to start modularizing the build infrastructure!

That modularity would only work for the build hook of the root package (a flutter app). Presumably the dependencies should be packages that work in Dart standalone. We could conceivably optionally depend in the Dart standalone packages if the package:flutter_hook does not depend on the Flutter SDK itself. Conditional import style. (But I believe conditional build hooks is an anti pattern.)

[mkustermann]

That modularity would only work for the build hook of the root package (a flutter app). Presumably the dependencies should be packages that work in Dart standalone. We could conceivably optionally depend in the Dart standalone packages if the package:flutter_hook does not depend on the Flutter SDK itself. Conditional import style. (But I believe conditional build hooks is an anti pattern.)

It's not about root package. Any package that is flutter specific (e.g. flutter plugin package) may want to use flutter-specific features of the build system (e.g. bundle proguard rules, java code, rely on flutter-specific configuration - be it "flavor"s or gradle versions etc)

Yes if a package wants to be independent of flutter, then it shouldn't require flutter configs / asset types to be available.

[dcharkes]

To make this a bit more explicit, the way that we envision Flutter-specific config to work would be via:

void main(List<String> args) async {
  await build(args, (input, output) async {
    if (input.config.hasFlutter) { // Or maybe we make `input.config.flutter` nullable.
      final String flavor = input.config.flutter.flavor;
      final outputDir = input.outputDirectoryShared.resolve('$flavor/');
      // Ensure flavor-specific assets exist.
    }
  });
});

Note that in dart test in flutter project one would not have a flavor.

The caching story would be as follows:

• The Flutter SDK keeps track of separate invocations with different flavors (everything inside input.config is part of the uniqueness of an invocation). So, reinvoking with the same flavor without any output.dependencies changing.
  • TODO(@dcharkes): Check that this actually works with the Targets in the Flutter build system with flutter assemble. If those targets are not flavor-aware, we might need to add an additional synthetic input to the asset building step.
• The hook writer needs to use separate output directories (or file names) in the shared output directory to avoid flavor-specific assets overwriting each other.