Code Generation With build_runner

Some code is repetitive boilerplate, like JSON parsing. Code generation writes it for you from annotations, so you stay accurate and fast. ⚙️

build_runner is Dart's tool that runs code generators over your project. It reads source files, finds annotations, and emits new files.

You add build_runner under dev_dependencies in pubspec.yaml, because it runs at build time and is never shipped with your app.

Generators write into a sibling file. You link to it with a part directive whose name ends in .g.dart by convention.

Trigger a one-time generation with the build command. It scans your code and creates or refreshes every .g.dart file.

During development, watch mode regenerates automatically whenever you save. It keeps generated files in sync without manual reruns.

If outputs clash with old files, add --delete-conflicting-outputs. It clears stale generated files so the fresh build can succeed.

Generators only act on declarations you annotate. The annotation tells the builder which class to process and what code to produce.

Treat every .g.dart file as read-only. The next build overwrites your changes, so edit the source and annotations instead.

Teams choose to commit generated files or add them to .gitignore and rebuild in CI. Either way, pick one policy and stay consistent.

Many packages plug into build_runner, like json_serializable and freezed. They share one builder pipeline, so a single command runs them all.

Which command regenerates code on every file save?

build_runner turns annotations into generated .g.dart files. Add it to dev_dependencies, run build or watch, and never edit the output. 🎉