Web compilers for users of
If you are using the autogenerated build script (going through
pub run build_runner <command> instead of handwriting a
then all you need is the
dev_dependency listed above.
By default, the
dartdevc compiler will be used, which is the Dart Development
If you would like to opt into
dart2js you will need to add a
file, which should look roughly like the following:
targets: $default: builders: build_web_compilers|entrypoint: # These are globs for the entrypoints you want to compile. generate_for: - test/**.browser_test.dart - web/**.dart options: compiler: dart2js # List any dart2js specific args here, or omit it. dart2js_args: - -O2
If you are using a custom build script, you will need to add the following builder applications to what you already have, almost certainly at the end of the list (unless you need to post-process the js files).
[ apply( 'build_web_compilers|ddc', [ (_) => new ModuleBuilder(), (_) => new UnlinkedSummaryBuilder(), (_) => new LinkedSummaryBuilder(), (_) => new DevCompilerBuilder() ], toAllPackages(), // Recommended, but not required. This makes it so only modules that are // imported by entrypoints get compiled. isOptional: true, hideOutput: true), apply('build_web_compilers|entrypoint', // You can also use `WebCompiler.Dart2Js`. If you don't care about // dartdevc at all you may also omit the previous builder application // entirely. [(_) => new WebEntrypointBuilder(WebCompiler.DartDevc)], toRoot(), hideOutput: true, // These globs should match your entrypoints only. defaultGenerateFor: const InputSet( include: const ['web/**', 'test/**.browser_test.dart'])), ]
In this release, the Dart front end for the
dev_compiler is changing from the
analyzer to the common front end. This should unify error
messages and general consistency across platforms, as this was one of the last
compilers left still using the analyzer as a front end.
While this is intended to be a transparent change, it is likely that there will be unintended differences. Please file issues if you experience something that seems broken or not working as intended.
Previously, all files with a
main that were matched by the input globs would
attempt to compile for the web. This caused an issue when there were non-web
applications in the default directories, which specifically happens a lot in the
test directory. Resolving this required custom globs in
Two changes were made to help handle this issue more gracefully, in a way that
often doesn't require custom
build.yaml files any more.
build.yamlthan waiting for us to detect it. This may change based on feedback.
testdirectory to only include the
test/**.dart.browser_test.dartfiles (other dirs remain unchanged).
testdir and running tests that way no longer works, as those entrypoints won't be compiled. You would need to configure the
generate_forto explicitly include
test/**_test.dartto restore that functionality (we will continue pushing on this in the future though to restore similar functionality).
build_testpackage will now output
<platform>_test.dartfiles based on your TestOn annotations, so using those where possible will help reduce build platform support warnings as well.
ddcworkers under a single name (
.dart.browser_test.dartfiles will be compiled under the
testdirectory, instead of all
targets: $default: builders: build_web_compilers|entrypoint: generate_for: - test/**_test.dart - web/**.dart
use-incremental-compileroption for the
build_web_compilers:ddcbuilder. This is enabled by default but can be disabled if running into build issues by setting it to
global_options: build_web_compilers:ddc: options: use-incremental-compiler: false
require.jsfiles, which it deletes during production builds.
$sdkpackage to resolve some issues with build output bloat.
dartdevcas your production compiler, you will need to disable the cleanup builder in
build.yaml(globally) like this:
global_options: build_web_compilers|sdk_js_cleanup: release_options: enabled: false
.digestsfile which contains transitive digests for an entrypoint.
ignore_cast_failuresoptions for the
build_web_compilers|entrypointbuilder. These will no longer have any effect and will give a build time warning if you try to use them.
window.postMessageduring initialization if the current context is a
<base>tag is used.
<base href="/.../">tag should start and end with a
/to be used as the base url for require js.
newkeyword for a working release on Dart 1 VM.
package:build_configto include version
package:archiveto include version
.js.mapfiles from the output directory in release mode.
.tar.gzoutputs produced by
Dart2Jsoutputs other than deferred part files.
dartdevccompiler to detect correct base url for require js.
enable_sync_asyncoption to the
build_web_compilers|entrypointbuilder, which defaults to
dartdevccompiler now respects the
<base href="/....">tags and will set them as the base url for require js.
dart2jsby default in release mode.
.packagesfile and use the new frontend with
dart2jsas a stopgap until we can add support for
dart2jscompiler. If you pass that argument with
.info.jsonfile will be copied the output.
--minify) enabled by default, similar to how it worked in
pub build. If you are adding custom
dart2jsoptions, make sure you still keep the
--minifyflag. Here is an example:
targets: $default: builders: build_web_compilers|entrypoint: generate_for: - web/**.dart options: compiler: dart2js dart2js_args: - --fast-startup - --minify - --trust-type-annotations - --trust-primitives
ignore_cast_failuresoption to the
build_web_compilers|entrypointbuilder which you can set to
trueto enable them.
LinkedSummaryBuilderinto a separate
testare now compiled by default instead of only the
_browser_test.dartfiles (minus vm/node test bootstrap files). This means the original tests can be debugged directly (prior to package:test bootstrapping).
dart2js. This can be configured using the top level
compileroption for the
build_web_compilers|entrypointbuilder. The supported options are
dartdevc(the default) and
dart2js. Args can be passed to
dart2js_argsoption. For example:
targets: <my_package>: builders: build_web_compilers|entrypoint: options: compiler: dart2js dart2js_args: - --minify
entrypoint, the exposed class also changed from
ddcBootstrapExtensionsince it is only required when using the dev compiler.
Add this to your package's pubspec.yaml file:
dependencies: build_web_compilers: ^2.1.1
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.1.1||Jun 12, 2019|
|2.1.0||May 23, 2019|
|2.0.2||May 22, 2019|
|2.0.1||May 21, 2019|
|2.0.0||Apr 24, 2019|
|1.2.2||May 31, 2019|
|1.2.1||Apr 17, 2019|
|1.2.0||Mar 14, 2019|
|1.1.0||Feb 1, 2019|
|1.0.2||Feb 1, 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 25, 2019, and provided a score, details, and suggestions below. Analysis was completed with status completed using:
Detected platforms: Flutter, other
lib/src/web_entrypoint_builder.dart. (-0.50 points)
lib/src/web_entrypoint_builder.dart reported 1 hint:
line 116 col 16: 'parseCompilationUnit' is deprecated and shouldn't be used.
The package description is too short. (-12 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_web_compilers.dart. Packages with multiple examples should provide
For more information see the pub package layout conventions.
|Dart SDK||>=2.3.0 <3.0.0|