[native_assets_cli] Make extensions more user-friendly

[dcharkes]

Currently, correctly dealing with protocol extensions requires one to access multiple pieces of information in the Dart API that are not connected:

• input.config.buildCodeAssets
• input.config.code
• input.assets.code (link input)
• output.assets.code.add

It is very easy to forget checking input.config.buildCodeAssets.

@mosuem suggested organizing the API in a way that makes whether an extension is enabled a single point in the Dart API.

For example:

• input.code (nullable, only non-null if extension is enabled)
• input.code!.config
• input.code!.assets (link input)
• output.code!.assets.add (the OutputBuilder needs to have access to the Input to decide whether .code is null or not)

@mosuem suggested making the output accessible through the input.

• input.code!.output.assets (@dcharkes Doesn't like the look of this, having output in the input.)

If we want to support fallback asset types (#2154), then a nullable object might not fit very well. Maybe then we should organize it as follows:

• input.code.build
• input.code.supported
• input.code.config (throws if build is false)
• input.code.assets (throws if build is false)
• output.code.assets.add (throws if input.build is false)

This gives us a place to document that build must be true on the other methods, but doesn't help much with the types statically.

I really like the idea of structuring the extension point in the Dart API in one place over having an extension point in multiple places as it is with the current solution. Thanks @mosuem! 🙏

[mosuem]

I think the problem is the disconnect between input.code and output.code. I think it is ugly to have the input and output connected - but if they are, we should make it visible. This would enable something like

final code = input.code;
if(code != null) {
  ... // all code pertaining to code assets, no ! in sight
}

instead of

final code = input.code;
if(code != null) {
  ... // all code pertaining to code assets

  output.code!.assets.add(...); //ugly ! - are we sure this is not null? If so, why not tell the user?
}

So a +1 to input.code?.output.assets from me!

As commented on #2154, I think the SDK should decide what is built. The hook code just builds whatever is needed. So nullability is fine.

[dcharkes]

So a +1 to input.code?.output.assets from me!

😆

Maybe we should have HookApi hookApi

• hookApi.code (nullable, only non-null if hookApi.input.buildAssetTypes contains code)
• hookApi.code!.input.config
• hookApi.code!.input.assets (link input)
• hookApi.code!.output.assets.add

But that doesn't look that amazing either.