[native_assets_cli] Unify metadata and assets

[dcharkes]

We currently have 3 types of output of a build hook:

• assets (for bundling)
• assets (for link hooks)
• metadata (for other build hooks)

The most common use cases for metadata are:

• Lazily downloading a native toolchain and communicating the path to that toolchain. (For example the Android NDK (Installing NDK automatically #976) or the Rust compiler.)
• Building a toolchain (for example your custom svg-to-tesselated or 3dmodel-to-shader)

Maybe there are other use cases but, we haven't come up with them yet.

If there's a use case for structured data, it might be fine to just put that structured data in a json file and make it a data asset.

Unifying these 3 types of assets would:

1. Simplify the API. (Currently we have addAsset(...) for assets for bundling and assetAsset(linkIn: 'some_package', ...) for sending it to a link hook, and addMetadata(...) for sending info to another build hook.)
2. Make dependency tracking per "asset" work properly for executables send to other build hooks ([native_assets_cli] Dependencies should be per asset #1208).

Then we need to come up with some name for these 3 types of "buildables".

• Probably we should only the things used for bundling "asset"s?

Thanks @mosuem @mkustermann @liamappelbe @HosseinYousefi for the input! And please leave any other thoughts and suggestions.

[dcharkes]

@bdero Just a heads up, we might break the metadata soon (or temporarily remove it until we find an API that we want to add to do this).

As a workaround, you could try to build the compiler in my_compiler/hook/build.dart and do dart run my_compiler:main to run my_compiler/bin/main.dart which would do the compilation inside my_package_using_compiler/hook/build.dart.

[dcharkes]

I thought I had posted an API sketch here earlier, but apparently I didn't.

My current way of thinking is:

  void addAsset(
    Asset asset, {
    Iterable<Uri>? dependencies,
    bool forBuildHooks, // if true, not bundled, but available to build hooks that have this build hook as direct dependency
    String? linkInPackage, // if set, not bundled directly but sent to specific link hook
  });

This way we can properly track dependencies per asset no matter where these assets are wired to:

• [native_assets_cli] Dependencies should be per asset #1208

[mosuem]

The API is starting to look a bit overloaded with arguments. I wonder if there is a way to simplify this. Maybe use asset types instead? This would make asset creation a bit more nested.

class MetadataAsset {
  final Asset asset;
}

class LinkableAsset {
  final String targetPackage;
  final Asset asset;
}

@lrhn, as you like to simplify APIs :)

[dcharkes]

The API is starting to look a bit overloaded with arguments. I wonder if there is a way to simplify this. Maybe use asset types instead? This would make asset creation a bit more nested.

class MetadataAsset {
  final Asset asset;
}

class LinkableAsset {
  final String targetPackage;
  final Asset asset;
}

@lrhn, as you like to simplify APIs :)

Or maybe we should have a "Routing" (name tbd) param instead. That would also give us a place to document the behavior.

addAsset(
  Asset asset, {
  Routing routing = const Routing.bundleInApp,
});

final class Routing {
  /// This asset will be bundled in the app by the Dart or Flutter SDK.
  static const Routing bundleInApp;

  /// This asset is available in build hooks of which the packages have a
  /// direct dependency on the package with this build hook.
  static const Routing forBuildHooks;

  /// The asset will not be bundled during the build step, but sent as input to
  /// the link hook of the specified package, where it can be further processed
  /// and possibly bundled.
  factory Routing.linkInPackage(String packageName)
}