Initially, we had the idea that the input and output for build.dart would be unstructured JSON/YAML, and that there would be multiple views on top of these JSONs. In this approach, package:native_assets_cli would be one such view. And we would introduce other views for other types of assets (icons, localization) ...

However, after some discussions with @mosuem, we realized that some of the things in the JSON would be better off shared:

• In the BuildOutput: the dependencies (used for caching -- whether build.dart should be reinvoked). This would also be required for resource shaking in localization.
• In the BuildConfig the targetOS would likely be used for deciding what icons to bundle.

If we add a concept of "data assets" to the native assets CLI, then we should reconsider the package name package:native_assets_cli to be something like package:build_script instead. (Suggestion taken from @gaaclarke)

For some reason the name "native assets" made it seem like it was only for linking in libraries. IMO "build scripts" is a better name.

Dart SDK tracking issue:

• Data assets feature sdk#54003

Flutter tracking issue:

• hook/build.dart Data assets support flutter/flutter#146264