[native_assets_cli] Drop Config suffixes v2

[dcharkes]

Addresses:

• [native_assets_cli] Move BuildConfig.targetOS to BuildConfig.codeConfig.targetOS, remove it entirely or extend to cover web #1738 (comment)

A variant of:

• [native_assets_cli] Drop Config suffixes v1 #1829

This PR normalizes the code and data specific APIs on the config, config builder, output and output builders under a .code and .data extension.

Example link hook code:

void main(List<String> args) async {
  await link(
    args,
    (config, output) async =>
        output.data.addAssets(treeshake(config.data.assets)),
  );
}

Example build hook code:

void main(List<String> arguments) async {
  await build(arguments, (config, output) async {
    if (config.code.targetOS == OS.android) {
      config.code.android.targetNdkApi;
    }

    output.code.addAsset( ... );
  });
}

This drops Config suffixes from the various config accessors.
This changes output.codeAssets.add( to output.code.addAsset(.

The weird quirk in this PR is that it has to provide an API for LinkConfig.code that gives both the CodeConfig getters and an assets getter. I tried using extension types to alleviate this, but extension types can only extend the type they are extending, not the first element of a tuple they are extending.

Separating the linkConfig.code : CodeConfig and linkConfig.assets.code : Iterable<CodeAsset> leads to a less symmetric API though:

• [native_assets_cli] Drop Config suffixes v1 #1829

Alternatively, we could also opt to land neither of the PRs. And stick with config.codeConfig.androidConfig and output.codeAssets.

[coveralls]

coverage: 87.807% (-0.2%) from 87.965%
when pulling 9939a39 on config-names-v2
into 8c16b6c on main.

[mosuem]

LGTM with some nits and more docs - but I like this API.

[mosuem]

This name is giving me Java flashbacks - how about CodeAssetCollector?

[mosuem]

This is indeed a bit ugly, but I don't know a way around it...

[mkustermann]

This doesn't seem very right to me. It mixes orthogonal concerns (code configuration and outputed assets)

[mosuem]

Nit: Why a switch instead of a simple if check?

[mosuem]

Similarly verbose as above - and not very understandable...

[mkustermann]

The weird quirk in this PR is that it has to provide an API for LinkConfig.code that gives both the CodeConfig getters and an assets getter.

Based on recent discussions with @mosuem @liamappelbe about what is used to hash the build directory and this PR restructuring, we may want to consider rename a few things and do the following

// build hook
main(...) asyc {
  await build((BuildInput input, BuildOutputBuilder output) {
    input.outputDirectory;
    input.config.{code,...} // <-- only this goes into hashing
    input.metadata.* // <-- metadata emitted from package deps we can utilize

    output.assets.code.add();
  });
}

// link hook
main(...) asyc {
  await link((LinkInput input, LinkOutputBuilder output) {
    input.outputDirectory
    input.config.{code,...}. // <-- only this goes into hashing
    input.assets.{code,data,...} // <-- symmetric to `hook/build.dart`'s `output.assets.{code,data,...}`

    output.assets.code.add();
  });
}

That would achieve

• very clear separation of configuration (target platform, ...) from input data (metadata, assets to be linked, etc)
• very clear what goes into build dir hash and what doesn't

This changes output.codeAssets.add( to output.code.addAsset(.

I prefer we don't use addAsset() and just have add() because it's somewhat clear that we're adding assets.
I prefer output.assets.code.add() that groups all assets under one output.assets.

@dcharkes wdyt?

[dcharkes]

Thanks @mkustermann and @mosuem for the input! I've replied to the refactoring suggestion in the original thread.

Overall SGTM. I'll close this PR.

This changes output.codeAssets.add( to output.code.addAsset(.

I prefer we don't use addAsset() and just have add() because it's somewhat clear that we're adding assets. I prefer output.assets.code.add() that groups all assets under one output.assets.

@dcharkes wdyt?

Please see #1829 where I explored that.