Context
We are using drift_dev in a large Dart workspace and saw a slow local codegen loop where the analyzer spent significant time re-walking a generated .g.dart file produced earlier in the same pipeline. In one run, the drift analyzer pass spent roughly 174s around a generated *.g.dart output before the overall build was stopped.
We can route around this locally with a combination of modular generation, tighter package boundaries, generate_for, and analyzer.exclude, but it raised a question about whether drift can avoid considering files it knows it generated as analyzer roots.
Question
Is there, or should there be, a way for drift_dev to avoid re-analyzing generated Dart outputs as root inputs?
Possible forms this could take:
- Honor
analyzer.exclude / build configuration more strictly when selecting analyzer roots.
- Exclude files matching outputs drift itself generated.
- Document the recommended
build.yaml / analyzer configuration for large workspaces where generated .g.dart files otherwise get pulled into the analyzer pass.
Why this matters
For large projects, generated outputs can become large enough that re-walking them dominates the inner loop. The current practical fix is to reorganize the drift surface and generated files so analyzer scope is smaller, but it would be helpful if the builder could avoid generated outputs that are not meaningful source roots.
Not a blocker
This is an informational upstream tracking issue. Modular generation and package scoping may be enough for our immediate migration, but I wanted to ask whether there is an intended upstream direction for generated-output analyzer exclusion.
Context
We are using
drift_devin a large Dart workspace and saw a slow local codegen loop where the analyzer spent significant time re-walking a generated.g.dartfile produced earlier in the same pipeline. In one run, the drift analyzer pass spent roughly 174s around a generated*.g.dartoutput before the overall build was stopped.We can route around this locally with a combination of modular generation, tighter package boundaries,
generate_for, andanalyzer.exclude, but it raised a question about whether drift can avoid considering files it knows it generated as analyzer roots.Question
Is there, or should there be, a way for
drift_devto avoid re-analyzing generated Dart outputs as root inputs?Possible forms this could take:
analyzer.exclude/ build configuration more strictly when selecting analyzer roots.build.yaml/ analyzer configuration for large workspaces where generated.g.dartfiles otherwise get pulled into the analyzer pass.Why this matters
For large projects, generated outputs can become large enough that re-walking them dominates the inner loop. The current practical fix is to reorganize the drift surface and generated files so analyzer scope is smaller, but it would be helpful if the builder could avoid generated outputs that are not meaningful source roots.
Not a blocker
This is an informational upstream tracking issue. Modular generation and package scoping may be enough for our immediate migration, but I wanted to ask whether there is an intended upstream direction for generated-output analyzer exclusion.