Daco Harkes

> 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...

Circling back on this issue after we have decided that: 1. Metadata is not part of checksums (#1803). 2. Hooks are invoked multiple times (per asset type, and for code...

Another direction of thinking is to change the intermediate "assets" that flow between build and link hooks to be more like metadata. E.g. not have a file by default, and...

@mkustermann mentioned that libraries being linked against in other packages are build hook -> build hook and are asset like. (For example `package:dart_c_api`. https://github.com/dart-lang/native/issues/839) However, since one is using the...

The SDKs now support asset routing from build hook to build hook and meta data is implemented on top of this. The old metadata is still part of the protocol...

Closing stale PRs, please reopen if still relevant.

> So the `flutter run` can decide which asset types it may support for hot-reload and just ask for those, no? I believe the caching would not work in that...

> Why is this any different in hot-reload? Is the _implementation_ currently setup to not support this, or is this a fundamental issue? This is a conceptual issue: We report...

An alternative design suggested by @HosseinYousefi: Center the hook interaction around whether something is a hot-restart invocation or not. * `BuildConfig` gets a `bool isHotRestart` getter. * `BuildConfig` gets a...

Whether we have dependencies per asset (https://github.com/dart-lang/native/pull/1368) is connected to whether our protocol has a concept of dry run. (Thanks @mkustermann!) * If we have a `dryRun` (possibly to be...