[native_assets_cli] Should the API be not a main function?

[dcharkes]

Should we consider using implementing an interface instead of having a main function for build.dart?

This would be in the style of the Builders of package:build.

Pros:

• Visibility of conceptually different invocations of main:
  • dry-run vs build
  • before kernel compilation and after (edit: or build vs tree-shake)

Cons:

• It will be harder to make another implementation. It would be going in the opposite direction of [native_assets_cli] Document the protocol #95.

[dcharkes]

Notes from discussion with @mkustermann:

Cons:

• Tight coupling between Dart/Flutter SDK and build.dart API. We would need to pin package:native_assets_cli like Flutter pins packages. A CLI based on YAML/JSON files with optional fields allows more slack.

@mkustermann Is this actually true con? If the API is instantiated by a JSON under the hood. And we generate a main.dart that basically parses the CLI and calls the methods from the API. Then adding optional fields would work in the same way as it works now. The situation we would have more tight coupling as you suggest is when we would actually import the code directly instead of going through a Process.run. But we can't actually do that, because dartdev could be a precompiled aot snapshot. So maybe your concern is invalid.

That being said, almost all build systems that we are aware of use scripts with a main: Rust build.rs, NodeJS post-install hooks, Python's setup.py. So it's probably best to stick with the convention of having a standalone script.

[dcharkes]

I don't think we're still considering this. We'll be sticking with a JSON protocol.