In a discussion with @jonasfj earlier, we discussed to disallow any other keys in the output file in order to ensure package authors implementing the protocol themselves don't prevent us from adding keys later.
Implementing this would mean that end users always need the newest Dart / Flutter SDK if the native_assets_cli used in their build.dart is new, otherwise it might output a key that is not yet accepted by the Dart / Flutter SDK. This might be an issue while we develop the package because we need to release new versions of native_assets_cli and native_assets_builder on pub before they can roll into flutter_tools (it doesn't use DEPS, but a normal pubspec.yaml). And it takes a couple of months for commits to reach Flutter and Dart stable.
Essentially, disallowing other keys in the output file makes adding keys to the output file a breaking change. I believe it's better to avoid causing breaking changes. So maybe it's better to not disallow other keys in the output file. wdyt @jonasfj
jonasfj
commented
1 year ago
In a discussion with @jonasfj earlier, we discussed to disallow any other keys in the output file in order to ensure package authors implementing the protocol themselves don't prevent us from adding keys later.
Implementing this would mean that end users always need the newest Dart / Flutter SDK if the native_assets_cli used in their build.dart is new, otherwise it might output a key that is not yet accepted by the Dart / Flutter SDK. This might be an issue while we develop the package because we need to release new versions of
native_assets_cliandnative_assets_builderon pub before they can roll intoflutter_tools(it doesn't use DEPS, but a normal pubspec.yaml). And it takes a couple of months for commits to reach Flutter and Dart stable.Essentially, disallowing other keys in the output file makes adding keys to the output file a breaking change. I believe it's better to avoid causing breaking changes. So maybe it's better to not disallow other keys in the output file. wdyt @jonasfj