Moving build_runner to the Context Menu in VS Code
Shorten build_runner run time & regenerate only needed files in just two clicks.
Quite a lot of Dart & Flutter projects rely on code generation, delegating the burden of writing boilerplate code to a script. Although the more the project grows, the longer & less attractive code generation becomes. I heard wild stories about code generation taking more than half an hour to rebuild everything (I’m sure there’s more). And simply using the watch
command wasn’t helping: a small change was still triggering a few minutes of rebuilding.
Luckily, my situation is better. On my current project, it takes 4 minutes for my laptop to generate the code. Not that long, I agree. But we lose the beauty of hot reload if we need to wait until code generation completes.
So how do we keep it short & convenient?
Configuring the generators
It is possible to tell specific code generation builders to work with needed files. For example, we can tell Freezed to generate only *_model.dart
files. For this, we need to configure in the build.yaml
file:
targets:
$default:
builders:
freezed:freezed:
generate_for:
include:
- lib/**model.dart
# Or we can limit it even more:
- lib/data/**_dto.dart
# Etc etc etc
With this, we make sure that Freezed doesn’t work, say, with *_screen.dart
or *_widget.dart
classes. Similarly, we can exclude
files.
While it’s great, it can still be quite time consuming to regenerate all the model classes in your project.
Utilizing build-filter
build_runner
has a parameter build-filter
that allows to specify which files to work with. It can be used for a single or multiple relative paths to files:
dart run build_runner build --release --build-filter=lib/data/ad
min.freezed.dart --build-filter=lib/data/admin.g.dart
With this command, only the specified files will be regenerated.
Note that this must be ran on generated files, not on source files. In the given example,
admin.dart
contains all the required freezed & json_serializable configuration whereas.freezed.dart
and.g.dart
are generated files.
But files are not always stored under lib/data
. Your project might have a complex & deep-nested folder structure making file paths long. Gathering these paths of required files, using them as build-filter
s, running a terminal command… Boring. Not mentioning we have to do it again for a new set of files.
Solution
… is quite simple. Somehow optimize code generation by collecting relative paths of the required files & passing it to build_runner automatically.
For example, we can move it to the context menu of the VS Code’s file explorer, so you can right click files and regenerate them. Like this:
Bringing it to your table
All you need to do is to install the build_runner Tools extension. After that, you will see 4 new commands in the context menu when you right click .dart
files or folders:
- Build / Watch this: runs
build_runner
on the selected files. It simply maps relative paths of the selected files tobuild-filter
params and launchesbuild_runner
. Must be ran on generated files like.g.dart
. - Build / Watch parts: unlike the “this” command, it reads the selected files / folders and collects all the
part
directives. Must be run on files likeadmin.dart
from the example above. The extension will automatically launchbuild_runner
on theadmin.g.dart
andadmin.freezed.dart
files since it’s referenced in the source file itself.
More examples and possible answers to your questions are in the extension’s description itself.
That’s it folks!
I couldn’t come up with a conclusion, so I’ll just put a philosophical statement here:
Time is one of the most valuable things in this world. There are better ways to spend it rather than waiting for code generation to complete.
Reach out to me in Telegram or join my technical blog there. I will be happy to have you.
Peace and light to your house.