Codegen and toolchain
One deterministic codegen pass is the source of truth for every generated file;
run it first, scope it tightly, and decide once whether its output lives in git.
Applies whenever a project uses
or
.
Read the reference for the task at hand:
references/codegen-scoping.md
— the generator inventory,
scoping tables, error-to-fix recovery map.
references/commit-vs-gitignore.md
— the two committed/gitignored strategies,
their tradeoffs, and the exact CI gate each one requires.
references/toolchain-and-workspace.md
— SDK pinning, analyzer/coverage
excludes, and the multi-package workspace layering (fenced, opt-in).
Run
(codegen → format → analyze) before a PR, and
scripts/check-codegen-hygiene.sh
to verify excludes and commit-policy parity.
Non-negotiable rules
- Codegen runs FIRST, before . Generated files may be
absent on a fresh clone or stale after editing an annotation. Analyzing that
tree emits misleading "missing part file" and "undefined class "
errors. Regenerate, then analyze — never chase the symptom at the call site.
- Always pass
--delete-conflicting-outputs
. Without it
refuses to overwrite an output from a renamed/deleted source and fails with a
wall of "conflicting outputs" text. That is not a bug to investigate.
- Never hand-edit a generated file. The next build silently reverts it and
takes your edit with it. Change the annotated source and rerun codegen.
- Scope every builder with in a per-package .
A change in one directory must not regenerate the whole tree. Point each glob
at the narrowest directory that owns the annotation.
- Decide commit-vs-gitignore ONCE, back it with the matching CI gate.
Gitignored → CI regenerates first, before analyze. Committed → CI regenerates
then runs as a freshness gate. Either is valid; a
policy without its gate is not (see
references/commit-vs-gitignore.md
).
- Mirror generated-file globs into the analyzer AND coverage excludes.
A glob that lints machine output wastes review; a glob missing from lcov
inflates coverage. Exclude the emitted suffix — verify it, do not guess.
- Pin the SDK; local must equal CI. The CI Flutter/Dart version must match
the pinned local version ( under FVM, or the tool the repo standardizes
on). A drift here reproduces "works on my machine" format/codegen churn.
- is a local edit-loop tool only. CI and the pre-analyze step always
use the one-shot command.
The canonical command
Run from the repository root:
bash
dart run build_runner build --delete-conflicting-outputs
This regenerates every builder —
,
,
,
,
— in one pass.
runs through the
Flutter tool but is treated identically (regenerated first, same commit policy):
bash
flutter gen-l10n # if not auto-triggered by `flutter pub get` via l10n.yaml
Fresh clone / after pull / after editing any annotation, the fixed order is:
build_runner build --delete-conflicting-outputs → format → analyze → test
Never reorder codegen after analyze. During an active edit session only, a
watcher rebuilds affected outputs on save:
bash
dart run build_runner watch --delete-conflicting-outputs
Scoping builders with build.yaml
Give every codegen-carrying package (or the single app package) its own
, and fence each builder's
at the narrowest directory
that owns its annotation. An unscoped root config fans out to every annotation in
the tree, so editing one
model regenerates unrelated
and
outputs. Copy
;
references/codegen-scoping.md
has the full
generator-to-suffix table and per-builder globs.
Commit vs gitignore: pick one, wire its gate
Both strategies are legitimate; they trade different risks (see rule 5). Gitignore
keeps the tree clean but needs a working toolchain to build. Committing survives a
broken future toolchain and makes schema diffs reviewable, but needs a
diff-collapse (
examples/gitattributes.example
) AND a mandatory
freshness gate — regenerate, then
git diff --exit-code -- '*.g.dart' '*.freezed.dart' '*.drift.dart'
. A policy
without its gate is not a policy. Both strategies, their tradeoffs, and the exact
gate each requires:
references/commit-vs-gitignore.md
.
Analyzer and coverage excludes
Committed OR gitignored, every
emitted generated suffix must be excluded from
BOTH the analyzer and the lcov coverage filter — verify the suffix the config
actually emits first, do not guess. A missed analyzer glob wastes review on
machine output; a missed (or mis-anchored) lcov glob inflates coverage with
untested code. A migration-test baseline dir that holds generated era-correct data
classes needs the analyzer exclude too — an autofix inside an exported schema
snapshot would corrupt migration verification (see
). The canonical
exclude blocks and the correctly anchored lcov patterns live in
references/toolchain-and-workspace.md
.
When multi-package (workspace)
Only for a repo that has genuinely outgrown one package. A single-app project
needs none of this.
- Link members with a native Dart pub workspace: in every
member pubspec plus a list at the root, producing ONE root
. Never add a per-package lockfile.
- If you layer Melos on top, use it for script orchestration only
(
melos run gen/format/analyze/test
), never for path linking — pub does the
linking. Filter the script to packages that depend on .
- Run once at the workspace root so every member regenerates in
the same pass; running inside one package dir leaves the others stale.
Anti-patterns
- Analyzing before regenerating — every downstream error is a phantom; fix
the order, not the code.
- Omitting
--delete-conflicting-outputs
— turns a routine rename into a
build wall.
- Hand-editing / to silence an error — reverted on the
next build; the real fix is in the annotated source.
- Committing generated code with no freshness gate — output silently drifts
from source and reviewers trust a lie.
- One unscoped root — every trivial edit regenerates the whole
tree and slows every build.
- Coverage/analyzer glob that matches the wrong suffix — fails silently in
the analyzer, loudly in lcov 2.x, and quietly inflates coverage.
- CI Flutter version ≠ pinned local version — reproducible format/codegen
churn nobody can explain.
- A generated migration test left with empty data lists — passes vacuously
() while proving nothing; fill it or delete it (see ).
Definition of done
Related skills
- See for the operational, low-freedom "run this exact command"
loop and its troubleshooting table.
- See for the Drift schema-snapshot and migration-test ritual the
codegen pass produces.
- See for the Drift/DAO data layer these generators feed.
- See for the analyzer ruleset and the excludes mirrored
here.
- See for where codegen and the freshness gate sit in the
pipeline.
- See for the lockfile and SDK-pinning mechanics.
References