Just confirming, has this been tested on Windows?

The windows test was failing - I applied for the cloudtop permissions and can now finally debug it!

It seems we want to run this method with two modes after this PR:

• CodeAssets + DataAssets
• DataAssets (web only)

It seems weird that we can have codeAssetSupport: false but we still need to supply an OS and Architectures

I suggest packaging the codeAssetSupport (with architectures and os), dataAssetSupport and isWeb in objects.

sealed class FlutterAssetConfig {}

class FlutterDataAssetConfig extends FlutterAssetConfig {}

class FlutterCodeAssetConfig extends FlutterAssetConfig {
  FlutterCodeAssetConfig(this.architectures, this.os);

  final List<Architecture> architectures;
  final OS os;
}

Since we seem to run this method with multiple asset types at the same time (and then invoke the hooks for the asset types separately in this method), the param needs to be as follows:

Future<DartHookResult> _runDartHooks({
  required List<FlutterAssetConfig> assetConfigurations, // or a Set, but that adds hashing
  // ...

Not in the isolated directory, so we can't use DataAssets here. The HookResult should contain something else than DataAsset and CodeAsset, it should return the info in a format not requiring to import package:native_assets_cli.

So we can't use package:native_assets_cli outside of isolated?

Corrrect, you can't use it here. We'll have to extract the info you need from DataAssets inside isolated/ and then make that info available here.

Can logic such as this be tested on the general shard (unit tests that mock running the hooks)? That requires less resources to run.

See test/general.shard/isolated/native_assets_test.dart with buildRunner: FakeFlutterNativeAssetsBuildRunner(.

I'll leave the balance between mocked-out-tests and full integration tests is something for Ben to decide on.