Too many packages loaded+built in workspace

[PiotrWpl]

Hi,

I have a monorepo project with multiple packages (27 to be more specific), and I'm using Melos to handle it. Unfortunately, after the recent project tech stack upgrade (Flutter from 3.29 to 3.35, Dart from 3.7.2 to 3.9.2, and different dependencies), I'm encountering a strange error while running the build_runner across the project with my melos steps.

buildrunner:clean:
    description: |
      Clean cache and run `build_runner` in all packages and apps
    steps:
      - for dir in apps packages; do find "$dir" -name ".dart_tool" -type d -exec rm -rf {} +; done
      - for dir in apps packages; do find "$dir" -name "build" -type d -exec rm -rf {} +; done
      - melos run pub:get
      - melos buildrunner:all

buildrunner:all:
    description: |
      Run `build_runner` to generate assets.
    run: |
      dart run build_runner build --delete-conflicting-outputs
    exec:
      failFast: true
      orderDependents: true
    packageFilters:
      dependsOn:
        - build_runner

Previously, with such code, we were able to successfully generate in parallel all the JSON serializations, api client, forms definition, local assets, and dependency injection files.
But now one builder is failing due to the non-existent files, which are part of another package (on which we have no dependency), and they are just not generated yet.

Example:

• We have a domain_package, data_package and common_package
• domain has no dependency on data and common
• data has dependency only on domain
• and common also has dependency on domain
• so there is no direct or transitive dependency between common and data

I run the build runner in a way as described above (a melos step), then:

• Previously generated files are being removed
• Next new files are successfully generated in the domain package
• And while generating dependency injection in data package and common package (they run in parallel, as there is no dependency between them), the build_runner in common fails due to the lack of .g.dart files in data

[common_package]: E injectable_generator:injectable_builder on data_package|lib/src/featureX/datasource/featureX_change_broadcaster_impl.dart:
[common_package]:   AssetNotFoundException: data_package|lib/src/featureX/dto/featureX_message_response_dto.g.dart 

My expectation would be not to fail the build runner due to a lack of files that are not only in the package on which we are not dependent, but also are not needed at all for the specific runner, and they will be generated later.

As a workaround, I had to redefine my melos steps to run the specific build runners in a sequence, but now the build time has increased a lot, so I would prefer to return to the solution where I can run them in parallel.

My new build_runner steps:

buildrunner:clean:
  description: |
    Clean cache and run `build_runner` in all packages and apps (except widgetbook).
  steps:
    - for dir in apps packages; do find "$dir" -name ".dart_tool" -type d -exec rm -rf {} +; done
    - for dir in apps packages; do find "$dir" -name "build" -type d -exec rm -rf {} +; done
    - melos run pub:get
    - melos buildrunner:assets
    - melos buildrunner:api
    - melos buildrunner:forms
    - melos buildrunner:di

buildrunner:assets:
  description: |
    Run `build_runner` to generate assets.
  run: |
    dart run build_runner build --delete-conflicting-outputs \
      --build-filter **/*.gen.dart
  exec:
    failFast: true
  packageFilters:
    dependsOn:
      - flutter_gen_runner

buildrunner:api:
  description: |
    Run build_runner to generate api related files (json, api clients).
  run: |
    dart run build_runner build --delete-conflicting-outputs \
      --build-filter **/*.g.dart
  exec:
    failFast: true
  packageFilters:
    scope:
      - data_package

buildrunner:forms:
  description: |
    Run build_runner to generate forms.
  run: |
    dart run build_runner build --delete-conflicting-outputs \
      --build-filter **/*.gform.dart
  exec:
    concurrency: 1
    failFast: true
    orderDependents: true
  packageFilters:
    dependsOn:
      - reactive_forms_generator

buildrunner:di:
  description: |
    Run build_runner to generate dependency injection configuration.
  run: |
    dart run build_runner build --delete-conflicting-outputs \
      --build-filter **/*.config.dart
  exec:
    concurrency: 1
    failFast: true
    orderDependents: true
  packageFilters:
    dependsOn:
      - injectable_generator

My Flutter and Dart details:

[✓] Flutter (Channel stable, 3.35.7, on macOS 26.0.1 25A362 darwin-arm64, locale en-US) [2.8s]
    • Flutter version 3.35.7 on channel stable at /Users/pw/fvm/versions/3.35.7
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision adc9010625 (7 days ago), 2025-10-21 14:16:03 -0400
    • Engine revision 035316565a
    • Dart version 3.9.2
    • DevTools version 2.48.0
    • Feature flags: enable-web, no-enable-linux-desktop, no-enable-macos-desktop, no-enable-windows-desktop, enable-android, enable-ios,
      cli-animations, enable-lldb-debugging

Some package details that could be important:

_fe_analyzer_shared: ^91.0.0
analyzer: 8.4.0
build: 4.0.2
build_runner: ^2.9.0
flutter_gen_runner: ^5.12.0
injectable_generator: ^2.9.0
reactive_forms_generator: https://github.com/Devalfaz/reactive_forms_generator
retrofit_generator: ^10.0.5
source_gen: 4.0.2

[davidmorgan]

You said that "common" has no dependency on "data", but then the log you posted doesn't make sense

[common_package]: E injectable_generator:injectable_builder on data_package|lib/src/featureX/datasource/featureX_change_broadcaster_impl.dart:
[common_package]:   AssetNotFoundException: data_package|lib/src/featureX/dto/featureX_message_response_dto.g.dart 

as build_runner definitely is running on data_package, it must have found it somehow :)

Are you sure there is no transitive dependency? You could check by looking at the .dart_tool/package_graph.json of the "common" package, is data_package mentioned in that file?

[PiotrWpl]

Yes, I know that it doesn't make sense. That's why I think it's a bug in the end.
Please take a look at the file (I anonymized some names), so you can see that there is no dependency between these two.

package_graph.json

[davidmorgan]

Hmm, well, let's see if we can figure out what's going on :)

Looking at the code that's reading the package config, unfortunately it's doing a lot--checking lots of possibilities, including searching upwards from the package directory

build/build_runner/lib/src/build_plan/package_graph.dart

Line 69 in 7cf516e

static Future<PackageGraph> forPath(String packagePath) async {

I wonder, can you repro the problem outside melos?

If you run for "common" by going to that package and running just "dart run build_runner build" on the command line, do you see any sign of it running for "data_package"? Maybe there's nothing in the logs, but perhaps there will be output under ".dart_tool/build/generated/data_package", that would mean for sure it's running for that package.

If that doesn't help, I guess the next thing to try is that I create a patch adding more logging and we can dig into what's going on.

I have a vague memory of someone else having issues with melos, since I'm not familiar with it does, let me just throw out there, if it does anything that makes the commands run different from if you ran them by hand, e.g. something to do with changing the current path, symlinking directories, ..., then obviously that could be contributing to the issue :)

[PiotrWpl]

First of all, thank you for taking a look at this issue!

So, when I removed all the .dart_tools in my project across the whole project, and after I ran
dart run build_runner build --delete-conflicting-outputs
in common directly (without melos) I can see that all my packages (including those that are not in the common package, like data) are listed in the .dart_tools/build/generated of the common package. Although it didn't fail, as these pre-generated files were already there in these packages.
And when I first removed all the .g.dart files from the data package, and ran the build_runner one more time (again without melos), then it also didn't fail.

FYI I can see in the logs, that at least the injectable_generator is traversing through the different packages (that are obviously not the dependency here), for example

Log overflowed the console, switching to line-by-line logging.
  0s injectable_generator:injectable_config_builder on 11 inputs: 1 output, 10 no-op
  25s injectable_generator:injectable_builder on 922 inputs: 256 output, 81 no-op; spent 9s analyzing, 7s reading, 4s sdk, 3s building, 2s resolving; myapp_camera|lib/src/application/camera_cubit.dart
  28s injectable_generator:injectable_builder on 922 inputs: 268 output, 98 no-op; spent 10s analyzing, 8s reading, 4s sdk, 3s building, 3s resolving; myapp_data|lib/gen/assets.gen.dart
  29s injectable_generator:injectable_builder on 922 inputs: 320 output, 158 no-op; spent 10s analyzing, 8s reading, 4s sdk, 4s building, 3s resolving; myapp_data|lib/src/core/di/platform_module.dart
  30s injectable_generator:injectable_builder on 922 inputs: 373 output, 229 no-op; spent 10s analyzing, 8s reading, 5s building, 4s sdk, 3s resolving; myapp_data|lib/src/ocr/repository/fake_ocr_repository_impl.dart
  32s injectable_generator:injectable_builder on 922 inputs: 416 output, 282 no-op; spent 11s analyzing, 9s reading, 5s building, 4s sdk, 3s resolving; myapp_data|lib/src/utils/json_mapper.dart
  33s injectable_generator:injectable_builder on 922 inputs: 452 output, 328 no-op; spent 11s analyzing, 9s reading, 5s building, 4s sdk, 3s resolving; myapp_feature1|lib/src/application/resend/resend_cubit_state.dart
  34s injectable_generator:injectable_builder on 922 inputs: 492 output, 370 no-op; spent 11s analyzing, 9s reading, 6s building, 4s sdk, 3s resolving; myapp_settings|lib/src/application/get_push_notification_info_cubit.dart
  35s injectable_generator:injectable_builder on 922 inputs: 510 output, 390 no-op; spent 12s analyzing, 9s reading, 6s building, 4s sdk, 4s resolving; myapp_feature2|lib/src/application/walkthrough_state.dart
  35s injectable_generator:injectable_builder on 922 inputs: 516 output, 406 no-op; spent 12s analyzing, 9s reading, 6s building, 4s sdk, 4s resolving
  Built with build_runner/jit in 48s with warnings; wrote 520 outputs.

But I was able to reproduce the issue, if I removed all the .dart_tool directories, and ran the:
dart run build_runner build --delete-conflicting-outputs
in two terminals at the same time, where one was opened for data, and the other one for common, so it's not melos issue, it's either build_runner or maybe the way how injectable_generator works, as build_runner allow for this?

[davidmorgan]

Hmm I guess your packages are in a workspace?

I just now noticed that if you're in a workspace then it's the workspace package config that gets the pubspec.lock file, my guess is that it's reading the whole workspace information by mistake and that's how it's finding the data package, I'll dig into it.

Not sure if I'll get to it today, but definitely soon :)

[PiotrWpl]

Yes, I'm using a workspace. Thanks!

[davidmorgan]

Okay, confirmed that's the problem: it reads the workspace config (.dart_tool/packag_config.json in the workspace root) then runs the build on all those packages.

For many builders this makes little difference, because many builders only run on the "root" package, the one you are currently in.

But some builders, such as web builds and package:inject_generator, also do work for all your transitive deps, outputting files for those to .dart_tool/build/generated. So they are doing unnecessary work. In your case it's failing while doing that unnecessary work due to a file disappearing :)

This definitely looks worth fixing, I'll see if I can figure something out.

Thanks for the detailed error reports :)