[native_assets_cli] 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.