dazel is a tool to generate an manage bazel workspaces for Dart projects.
NOTE: dazel requires an existing installation of bazel
If you're familiar with
pub run, then
dazel is easy. Start by
dev_dependency on the
You can run
dazel on a typical
my_new_package/ bin/ lib/ web/ pubspec.yaml
$ cd my_new_package $ pub run dazel init
If you don't have a project, you can use our
workspace folder of examples. See
tool/presubmit.dart for some examples.
bazel run files in
# Assume you have bin/hello.dart # We automatically generate a "hello_bin" target in your BUILD file. $ bazel run :hello_bin
You can also run a development sever for your web application:
# Assume you have web/main.dart, and web/index.html. $ pub run dazel serve
Oh, and did we mention support for the Dart dev compiler?
The dazel server supports both dart code on Dartium and js compiled with DDC.
We automatically generate a bunch of file for you - these should not be checked
in to your repository - you can safely ignore them when commiting. Here is an
example snippet you can include in a
/bazel-* .dazel packages.bzl BUILD WORKSPACE
You may also want to exclude the
bazel-* folders from the Dart analyzer
.analysis_options file. This prevents the Dart analyzer from
accidentally "seeing" generated and copied code and needlessly analyzing it.
analyzer: exclude: - 'bazel-*/**'
Customizing the build behavior of a package is done by creating a
file, which describes your configuration. Any packages that use code generation
(or use Transformers when running with
pub) will need to use a
to set this up. This includes packages which are dependencies.
It is fairly common for a package to want to split up their sources into multiple targets which each implement a particular feature. Specifically, this is useful if your package has some sources which are web friendly, and others which are not.
To split up a package add a
targets section to your
build.yaml file, which
defines the different targets that you wish to be generated. This is a map of
target names to configuration. Each target config may contain the following
true, this is the target a users package will depend on if they don't have a custom build.yaml file.
webcompatible, it won't be compiled with the dart dev compiler, but that is the only effect of this attribute today.
builderssection of their build.yaml.
List<String>with the names of the builders run on the library.
sources. The files to treat as inputs to all
builders. Supports glob syntax.
targets section for a package with two targets and some builders
targets: web: default: true sources: - "lib/a.dart" - "lib/src/**" exclude_sources: - "lib/transformer.dart" - "lib/src/transformer/**" dependencies: - "some_package" - "some_package:web" builders: - "some_builder_name" generate_for: - "lib/a.dart" transformer: platforms: - "vm" sources: - "lib/transformer.dart" - "lib/src/transformer/**" dependencies: - "barback"
Builders in your package (similar to transformers)
If users of your package need to apply some code generation to their package,
then you can define
Builders (from [package:build]
(https://pub.dartlang.org/packages/build)) and have those applied based on the
You tell dazel about your
Builders using the
builders section of your
build.yaml. This is a map of builder names to configuration. Each builder
config may contain the following keys:
Builderclass. This should always be a
List<String>which contains the names of the top-level methods in the imported library which are a function fitting the typedef
Builder factoryName(List<String> args). When multiple builders are used the create a pipeline - the outputs of the first builder become the inputs into the next builder.
input_extension, a matching file with each of
output_extensionsmust be output.
targets: # The target containing the builder sources. _my_builder: # By convention, this is private sources: - "lib/src/builder/**/*.dart" - "lib/builder.dart" dependencies: - "build" - "source_gen" builders: # The actual builder config. my_builder: target: ":_my_builder" import: "package:my_package/builder.dart" builder_factories: ["myBuilder"] input_extension: ".dart" output_extensions: - ".my_package.dart"
bazel. It's now called
dazel buildcommand, which can build a web app and create a deployable directory for it (using dart2js), similar to
dazel build web/index.html.
--output-dirwhich defaults to
deploy. The abbreviation
ois supported for this argument as well.
bazelcommand to subcommand
Add this to your package's pubspec.yaml file:
dependencies: dazel: "^0.3.5"
You can install packages from the command line:
$ pub get
$ flutter packages get
Alternatively, your editor might support
pub get or
Check the docs for your editor to learn more.
|0.3.5||Mar 20, 2017|
|0.3.4||Mar 7, 2017|
|0.3.3||Feb 24, 2017|
|0.3.2||Feb 17, 2017|
|0.3.1||Feb 6, 2017|
|0.3.0||Feb 4, 2017|
We analyzed this package, and provided a score, details, and suggestions below.
Describes how popular the package is relative to other packages. [more]
Code health derived from static analysis. [more]
Reflects how tidy and up-to-date the package is. [more]
Weighted score of the above. [more]
Detected platforms: Flutter, web, other
No platform restriction found in libraries.
The description is too short.
Add more detail about the package, what it does and what is its target use case. Try to write at least 60 characters.
Package is pre-v1 release.
While there is nothing inherently wrong with versions of
0.*.*, it usually means that the author is still experimenting with the general direction API.
Maintain an example.
Create a short demo in the
example/directory to show how to use this package. Common file name patterns include:
example.dartor you could also use
|Dart SDK||> 1.19.0|