[native_assets_cli] `config.xxxConfig` extensibility

[dcharkes]

Currently config.codeConfig (or renamed to be config.code) returns a CodeConfig object which no longer has access to the underlying JSON.

native/pkgs/native_assets_cli/lib/src/code_assets/config.dart

Lines 24 to 26 in 9596c1f

	extension CodeAssetLinkConfig on LinkConfig {
	/// Code asset specific configuration.
	CodeConfig get codeConfig => CodeConfig(this);

This makes it impossible for Flutter to extend the code config (#1836). We should consider fully leaning in to extensibility so that Flutter can introduce a config.codeConfig.flutterConfig.

Some ideas:

1. Have all XxxConfig classes have a .json as escape hatch that gives access to the root JSON or nested JSON
2. Have all .xxxConfig return an extension type around the root JSON rather than a class with the syntactically parsed fields.

Since we want the JSON format to be extensible, we should make it extensible not only at the root but also in nested keys. And for the Dart code belonging to those extensions to be able to provide extensions to those APIs they need to be able to access the JSON from the API object.

cc @mkustermann

[mkustermann]

This is somewhat by-design. It gets very hairy otherwise: We'd start having protocol extensions on other protocol extensions on other protocol extensions.

The simple thing (which we currently have): We have a base protocol. Then we have extensions that use top-level keys in the json. The managing of that namespace is up to the extension and no 3rd parties should meddle with it.

(Imagine package:code_assets be developed by team X. Now flutter team adds a new json key config.code.Foo to X protocol (but team X doesn't know about it). Then team X later on decides to add key config.code.Foo in the json - possibly with different meaning. Now we have a collision: two teams use field config.code.Foo for two different purposes.)

[dcharkes]

Protocol extensions on protocol extensions would allow package:native_toolchain_c to import package:code_asset and package:code_asset_flutter and operate only on CodeConfig and access the flutter extension on CodeConfig if provided.

And it would allow symmetry of where the Flutter C API is available in the config with where the Dart C API would be available in the config.

But yea, it does get rather hairy.

(And maybe symmetry between the Dart and Flutter C APIs should be a non-goal The Dart DL API is very different because we provide the function pointers from the VM. So it is available in every embedder where dart:ffi is available.)

Okay, idea considered, and dismissed.

[mkustermann]

And it would allow symmetry of where the Flutter C API is available in the config with where the Dart C API would be available in the config.

Is the flutter.h not also an flutter embedder API (used for other C++ apps that want to embed flutter) rather than an API for plugins to talk to? Or is it both?

I'm not actually sure whether we would want to make the dart_api_dl.h available in the config.code.* either. One thing we may eventually want to do is add a config.dart.sdk - pointing to the Dart SDK. So all tools within the Dart SDK would be available to hook authors - including the include/*.h directory (hacky way would be to use Platform.executable from a hook and navigate to ../include - better don't mention this here ...).

Not sure, but I think it's a separate discussion how to handle dart_api_dl.h and I wouldn't be surprised if we handle it similar to flutter.h.