-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Description
I stumbled upon some weird looking code in some of our testing fakes:
flutter/packages/flutter_tools/test/general.shard/isolated/fake_native_assets_build_runner.dart
Lines 25 to 26 in 97ca57c
| final BuildResult? Function(BuildConfig)? onBuild; | |
| final LinkResult? Function(LinkConfig)? onLink; |
flutter/packages/flutter_tools/test/general.shard/isolated/fake_native_assets_build_runner.dart
Lines 37 to 68 in 97ca57c
| @override | |
| Future<BuildResult?> build({ | |
| required List<String> buildAssetTypes, | |
| required BuildConfigValidator configValidator, | |
| required BuildConfigCreator configCreator, | |
| required BuildValidator buildValidator, | |
| required ApplicationAssetValidator applicationAssetValidator, | |
| required Uri workingDirectory, | |
| required bool linkingEnabled, | |
| }) async { | |
| BuildResult? result = buildResult; | |
| for (final Package package in packagesWithNativeAssetsResult) { | |
| final BuildConfigBuilder configBuilder = | |
| configCreator() | |
| ..setupHookConfig( | |
| packageRoot: package.root, | |
| packageName: package.name, | |
| buildAssetTypes: buildAssetTypes, | |
| ) | |
| ..setupBuildConfig(dryRun: false, linkingEnabled: linkingEnabled) | |
| ..setupBuildRunConfig( | |
| outputDirectory: Uri.parse('build-out-dir'), | |
| outputDirectoryShared: Uri.parse('build-out-dir-shared'), | |
| ); | |
| final BuildConfig buildConfig = BuildConfig(configBuilder.json); | |
| if (onBuild != null) { | |
| result = onBuild!(buildConfig); | |
| } | |
| buildInvocations++; | |
| } | |
| return result; | |
| } |
onBuild takes a BuildConfig (single hook invocation), but outputs a BuildResult which is the aggregated of all hook invocations. The implementation then does a loop over all packages and simply overwrites the result if there is more than one package with native assets. Unsurprisingly, we don't have any invocations with more than one package with native assets.
This should be rewritten in one of the two following ways:
final BuildOutput? Function(BuildConfig)? onBuild;and loop over all packages and combine the results, orfinal BuildResult? Function()? onBuildand don't loop over the packages.
If this should be a shallow mock, it should just record what it is invoked with and not do anything fancy. So I'm leaning towards option 2.
cc @mkustermann you added the loop over the packages (presumably to get access to a BuildConfig), any opinions?