This page describes the build_runner package and its commands.
You don’t usually need to use build_runner directly, except for running component tests from the command line. Instead, use the webdev tool to build and serve apps.
Setting up build_runner
build_runner, add these dev dependencies to your app’s pubspec:
dev_dependencies: # ··· build_runner: ^0.10.0 build_test: ^0.10.2 build_web_compilers: ^0.4.0
build_test package is optional; add it if you’ll be testing your app.
As usual after
pubspec.yaml changes, run
pub get or
$ pub get
Build config files
You can customize build_runner behavior using build config files. The default
build config filename is
You can also create named config files like
For example, if you have a build config file named
build.debug.yaml, use it
— instead of
build.yaml — like this:
$ pub run build_runner build --config debug
test command to run your app’s component tests:
pub run build_runner test [--fail-on-severe] -- -p <platform>
--fail-on-severe flag prevents tests from being run if there is a
severe build error. For a complete list of command line options run
build_runner test -h.
-- are passed directly to the test package runner. To see
all command-line options for the test runner, use this command:
build_runner test -- -h.
For example, this is how you’d run component tests in Chrome:
$ pub run build_runner test --fail-on-severe -- -p chrome
build command to build your web app:
pub run build_runner build [--release] [--output <dirname>] ...
The first build is the slowest. After that, assets are cached on disk and incremental builds are much faster.
To continuously run builds as you edit, use the
$ pub run build_runner build --release
For more information, see Switching to dart2js.
To run a development server, use the
$ pub run build_runner serve
By default this serves the
test directories, on ports
serve command runs, every change you save triggers a rebuild.