|Number of watchers on Github||57|
|Number of open issues||1|
|Average time to close an issue||4 months|
|Average time to merge a PR||about 13 hours|
|Open pull requests||2+|
|Closed pull requests||14+|
|Last commit||almost 2 years ago|
|Repo Created||about 5 years ago|
|Repo Last Updated||almost 2 years ago|
|Organization / Author||dart-lang|
|Do you use source_gen? Leave a review!|
|View source_gen activity|
|View on github|
|Fresh, new opensource launches 🚀🚀🚀|
Trendy new open source projects in your inbox! View examples
source_gen provides utilities for automated source code generation for Dart:
It's main purpose is to expose a developer-friendly API on top of lower-level
packages like the analyzer or
build. You don't have to use
source_gen in order to generate source code;
we also expose a set of library APIs that might be useful in your generators.
source_gen is a package, not an executable, it should be included as
a dependency in your project. If you are creating a generator for others to use
(for example, a JSON serialization generator) or a library that builds on top
source_gen include it in your pubspec
If you're only using
source_gen in your own project to generate code, and
then you publish that code (generated code included), then you can simply add
Once you have
source_gen setup, you should reference the examples below.
GeneratorForAnnotation class and
call your generator for a Dart library or for each element within a library
tagged with the annotation you are interested in.
source_gen is based on the
build package. Use a
LibraryBuilder to wrap your
Generator as a
Builder which can be run using
a build system compatible with
package:build. See the build package
documentation for information on running Builders.
Build is a platform-agnostic framework for Dart asset or code generation that is pluggable into multiple build systems including barback (pub/dart transformers), bazel, and standalone tools like build_runner. You could also build your own.
source_gen provides an API and tooling that is easily usable on
build to make common tasks easier and more developer friendly. For
PartBuilder class wraps one or more
Generator instances to make a
part of files, while the
wraps a single Generator to make a
Builder which creates Dart library files.
Dart transformers are often used to create and modify code and assets as part of a Dart project.
Transformers allow modification of existing code and encapsulates changes by
having developers use
Unfortunately the API exposed by transformers hinder fast incremental builds,
output caching, and predictability, so we introduced builders as part of
source_gen provide for a different model: outputs must be
declared ahead of time and code is generated and updated as part of a project.
It is designed to create part or standalone files that augment developer
maintained Dart libraries. For example AngularDart uses
compile HTML and annotation metadata into plain
Unlike transformers, generated code MAY be checked in as part of your project source, although the decision may vary depending on project needs.
Generated code SHOULD be included when publishing a project as a pub
package. The fact that
source_gen is used in a package is an implementation
TypeCheckernow throws an
UnresolvedAnnotationExceptionwith a more detailed exception body (and properties useful for further debugging) instead of
Could not resolve @null.
PartBuildernow have a more readable
toString(), which is useful when emitting a warning or error in a build system. For example you may see
Generating .g.dart: MyBuilderinstead of
Instance of LibraryBuilderin your build logs.
ConstantReader.revive() now properly returns no URL fragment
when the constant expression is resolved from a top-level or static-field.
The documentation had said otherwise, and it was impossible to tell the
difference between a constructor and a field. Now, fields are always in
the form of accessor =
Fix file URIs on windows.