aggregate builder not rebuild when one of multiple output files is deleted

[lcdsmao]

Thank you for taking the time to file an issue!

In order to route, prioritize, and act on this as soon as possible please include:

Dart SDK Version (dart --version)

Dart SDK version: 2.17.1 (stable) (Tue May 17 17:58:21 2022 +0000) on "macos_x64"

What package(s) from this repo you are using, and the version (i.e. build_runner 0.7.12)

• build: 2.3.0
• build_runner: 2.2.0

What builder(s) you are using (or writing yourself). Try to give a short summary of what they do.

I am trying to build an aggregate builder that generates multiple files.
For example, we have the following buildExtensions:

  @override
  Map<String, List<String>> get buildExtensions => const {
        r'$package$': [
          'lib/foo.gen.dart',
          'lib/bar.gen.dart',
        ],
      };

First, we run the build_runner and generate all those files.
Then if I delete the first file (lib/foo.gen.dart) and run build_runner again, files will be generated again properly.
But if I delete the second file (lib/bar.gen.dart) and run build_runner again, files won't be generated.

Here is the repo that reproduces this bug:
https://github.com/lcdsmao/aggregate_builder_bug/blob/main/lib/builder.dart

cd example
dart pub get
dart run build_runner build
# files should be generated

rm lib/foo.gen.dart
dart run build_runner build
# files generated again

rm lib/bar.gen.dart
dart run build_runner build
# files are not generated

I am trying to fix a bug of flutter_gen, and facing this bug.

[jakemac53]

Going to try and take a look at this today

[jakemac53]

build/build_runner_core/lib/src/generate/build_impl.dart

Line 685 in 07d1aaf

var firstOutput = outputs.first;

this line looks like the issue - when a file is manually deleted which is one of many outputs, the assumption here doesn't hold.

Can fix it by either checking all outputs to see if any are invalidated, or invalidating all the outputs of the same build step when we see the delete.

[jakemac53]

Thanks for the full reproduction repo @lcdsmao that helped a lot with diagnosing the issue efficiently! I have a fix out and should be able to publish it later today or tomorrow.