This package provides generic module builders which can be used to create custom
compilation pipelines. It is used by
build_vm_compilers package which provides standard builders for the web
and vm platforms.
There should be no need to import this package directly unless you are
developing a custom compiler pipeline. See documentation in
build_vm_compilers for more details on
building your Dart code.
The overall process for emitting modules follows these steps:
.module.libraryasset for every
.dartlibrary containing a description of the directives (imports, exports, and parts), a list of the
dart:imports used, and a determination of whether the library is an "entrypoint". Entrypoint libraries are either those which are likely to be directly imported (they are under
lib/src/) or which have a
main. Only the libraries that can be imported (they aren't part files) will have an output. This step is mainly separated out for better invalidation behavior since the output will change less frequently than the code. The outputs from this step are non differentiated by platform.
.meta_moduleassets. This is an aggregation of the
.module.libraryinformation with a first run at creating a module structure. The output depends on the algorithm, described below. The outputs from this step are specific to a platform and will indicate which libraries contain unsupported
dart:imports for a platform. Conditional imports will also be resolved to a concrete dependency based on the platform. In this step the dependencies of modules references the imported library, which may not match the primary source of the module containing that library.
.meta_module.cleanassets. This step performs an extra run of the strongly connected components algorithm so that any libraries which are in an import cycle are grouped into a single module. This is done as a separate step so that it can be sure it may read all the
.meta_moduleresults across packages in a dependency cycle so that it may resolve import cycles across packages. As modules are merged due to import cycles the new module becomes the union of their sources and dependencies. Dependencies are resolved to the "primary source" of the module containing the imported library.
.moduleassets which contain a filtered view of the package level meta-module specific to a single module. These are emitted for the "primary source" of each module, as well as each library which is an entrypoint.
The fine-grained module algorithm is straightforward - any dart library which can be it's own module, is it's own module. Libraries are only grouped into a module when there is an import cycle between them.
.meta_module step filters unsupported libraries and does no clustering.
Import cycles are resolved by the
The coarse-grained module algorithm attempts to cluster libraries into larger
modules without bringing in more code than may be imported by downstream code.
It assumes that libraries under
lib/src/ won't be imported directly outside of
the package. Assuming that external packages only import the libraries outside
lib/src/ then no code outside of the transitive imports will be brought in
due to module clustering.
.meta_module step performs strongly connected components and libraries
which are in an import cycle are grouped into modules since they can't be
ordered otherwise. Within each top level directory under the package (
test/, etc) the libraries are further bundled into modules where possible.
Each "entrypoint" library is always kept in it's own modules (other than in the
case of import cycles). Non entrypoint libraries are grouped where possible
based on the entrypoints that transitively import them. Any non-entrypoint which
is only transitively imported by a single entrypoint is merged into the module
for that entrypoint. Any non-entrypoints which are imported by the same set of
entrypoints are merged into their own module. The "primary source" for any
module is always the lowest alpha-sorted source, regardless of whether it is an
entrypoint. As libraries are merged the module becomes the union of their
sources and dependencies.
hasMainboolean to the
isEntrypointfor determining whether or not to copy module files for application discovery.
computeTransitiveDepsto do error checking for the root module as well as transitive modules.
.modulefiles for all entrypoints to ease discovery of modules for compilers.
Moduleand replace with a static
Module.merge. Module instances are now immutable.
DartPlatformno longer has hard coded platforms, and its constructor is now public. Anybody is now free to create their own
dart.library.isolateconditional imports for the DDC platform.
dart2jssnapshot arguments for upcoming SDK.
dart2jsworker and restricting sdk version.
detachedWithStdioif no terminal is connected.
dartdevc --kernelinstead of
Moduleconstructor has an additional required parameter
isSupported, which indicates if a module is supported on that module's platform.
dart.library.*constants are supported.
build_modules|modulesbuilder, you now need to configure the builder for each specific platform:
targets: $default: build_modules|dartdevc: options: strategy: fine
The supported platforms are currently
kernelSummaryExtension, and renamed the
KernelBuilder. The new builder can be used to create summaries or full kernel files, and requires users to give it a custom sdk.
.module.libraryfiles which are produced by the
moduleLibrayBuilder. Clients using the automatically generated build script will get this automatically. Clients which have manually written build scripts will need to add it.
package:scratch_spaceand don't manually clear it out between builds. This provides significant speed improvements for large projects.
metaModuleCleanExtensionpublicly for usage in tests and manual build scripts.
.module and summary files from the output and server.
ModuleBuilder strategies. By default the
coarse strategy is used
for all non-root packages and will create a minimum number of modules. This
strategy can not be overridden. However, for the root package, the
strategy will be used which creates a module for each strongly
connected component. You can override this behavior by providing
targets: $default: builders: build_modules|modules: options: strategy: coarse
computeTransitiveDependenciesnow throws a
MissingModulesExceptioninstead of logging a warning if it discovers a missing module.
terminateWorkers. This only really surfaces in test environments.
Add this to your package's pubspec.yaml file:
dependencies: build_modules: ^2.3.0
You can install packages from the command line:
$ pub get
$ flutter pub get
Alternatively, your editor might support
pub get or
flutter pub get.
Check the docs for your editor to learn more.
Now in your Dart code, you can use:
|2.3.0||Jun 4, 2019|
|2.2.0||May 23, 2019|
|2.1.3||May 21, 2019|
|2.1.2||Apr 24, 2019|
|2.1.1||Apr 24, 2019|
|2.1.0||Apr 18, 2019|
|2.0.0||Apr 12, 2019|
|1.0.11||May 31, 2019|
|1.0.10||Apr 1, 2019|
|1.0.9||Mar 4, 2019|
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]
We analyzed this package on Jun 21, 2019, and provided a score, details, and suggestions below. Analysis was completed with status completed using:
Detected platforms: Flutter, other
The package description is too short. (-20 points)
Add more detail to the
description field of
pubspec.yaml. Use 60 to 180 characters to describe the package, what it does, and its target use case.
Maintain an example. (-10 points)
Create a short demo in the
example/ directory to show how to use this package.
Common filename patterns include
build_modules.dart. Packages with multiple examples should provide
For more information see the pub package layout conventions.
|Dart SDK||>=2.3.0-dev.0.1 <3.0.0|