BREAKING CHANGE:
The following deprecated devkit builders options have been removed:
- `skipAppShell:` This has no effect
- `evalSourceMap`: This done to improve performance in older versions of the CLI and is no longer needed
- `vendorSourceMap`: Use `sourceMap.vendor` instead
- `profile`: Use `NG_BUILD_PROFILING` environment variable instead
BREAKING CHANGE
Deprecated browser builder option `es5BrowserSupport` has been removed. The inclusion for ES5 polyfills will be determined from the browsers listed in the browserslist configuration.
Depending on CommonJS modules is know to cause optimization bailouts. With this change when running a browser build and scripts optimization is enabled we display a warning.
To suppress the warning for a particular package, users can use the `allowedCommonJsDepedencies` builder options.
Example:
```
"build": {
"builder": "@angular-devkit/build-angular:browser",
"options": {
...
"allowedCommonJsDepedencies": ["bootstrap"]
},
}
```
Reference: TOOL-1328
When having differential loading enabled we only add the `sourceMappingURL` comment when optimization is enabled, because we only process these bundles when we enabling optimization.
With this change we now process such bundles even when optimization is disabled and add `sourceMappingURL` when source maps are enabled and not hidden.
Closes#16522
Fixes#15792.
Previously, budgets would include content for both versions of a differential build. Thus the `initial` budget would count content from the ES5 **and** ES2015 bundles together. This is a very misleading statistic because no user would download both versions. I've updated the budget calculators to take this into account and generate size values for both builds which are then checked independently of each other.
The only calculators I changed are the `InitialCalculator` (for computing `initial` bundle sizes) and `BundleCalculator` (for computing named bundles). Since budgets are handled by Webpack for builds without differential loading, the `initial` bundle will always have those two sizes. The `BundleCalculator` might reference a bundle which does not have differential loading performed (such as a CSS file), so it emits sizes depending on whether or not multiple builds were found for that chunk.
Most of the other calculators don't really need to take differential loading into account. `AnyScriptCalculator` and `AnyCalculator` already apply on a file-by-file basis, so they generate sizes for both build versions already. `AnyComponentStyleCalculator` only applies to CSS which does not have differential builds.
The wierd ones here are `AllCalculator` and `AllScriptCalculator` which reference files with and without differential builds. Conceptually, they should be separated, as a "total" budget specified by an app developer probably wanted it to mean "the total resources a user would have to download", which would only be one differential build at a time. However, I don't see a good way of identifying which assets belong to which differential build. Even if an asset belongs to a chunk with differential builds, we don't know which build takes which assets into account. I decided to leave this for the time being, but it is probably something we should look into separately.
Since budgets take differential loading into account, users might reasonably want to set different budgets for different builds (ie. "initial-es2015 bundle should be capped at 100k, but initial-es5 bundle can go to 150k"). That's more of a feature request, so I also left that out for a future PR.
Refs #15792.
Static files listed in `angular.json` were being accounted in the `initial` bundle budget even when they were deferred asynchronously with `"lazy": true` or `"inject": false`. Webpack belives these files to be `initial`, so this commit corrects that by finding all extra entry points and excluding ones which are explicitly marked by the application developer as asynchronous.
One edge case would be that the main bundle might transitively depend on one of these static files, and thus pull it into the `initial` bundle. However, this is not possible because the files are not present until the end of the build and cannot be depended upon by a Webpack build step. Thus all files listed by the application developer can be safely assumed to truly be loaded asynchronously.
Refs #15792.
This provides access to all the size information necessary because all build steps have already completed. This commit is roughly a no-op because it simply moves the budget checks (for different builds) to be executed post-build.
The lone exception is the AnyComponentStyle budget. Component stylesheet files are not emitted after the build is completed, so there is no size information to work with. Instead, these budgets are checked during a separate plugin (exected for different builds **and** non-differential builds).
All locale i18n options now support an object form which allows a base HREF to be defined for the locale. Each locale can now optionally define a custom base HREF that will be combined with the base HREF defined for the build configuration. By default if the shorthand form for the locale is used or the field is not present in the longhand form, the locale code will be used as the base HREF. To disable automatic augmentation a base HREF value of an empty string (`""`) can be used. This will prevent anything from being added to the existing base HREF.
For common scenarios, the shorthand form will result in the preferred and recommended outcome of each built locale variant of the application containing a defined base HREF containing the locale code.
A target of es2015 was previously assumed when using differential loading. This could result in erroneously downleveling an es2016+ output file instead of generating a new es5 output file.
At the moment we are relying on source content to determine if the compilation is under Ivy or VE. However, we do know what compilation we are in from the parsed tsconfig.
With this change we use the `enableIvy` to set the analytics metric
In applications that make heavy use of lazy routes and ES2015 libraries, this option can improve bundle sizes. It might also break your bundles in ways we don't understand fully, so please test and report any problems you find.
NOTE: the following are known problems with experimentalRollupPass
- vendorChunk, commonChunk, namedChunks: these won't work, because by the time webpack sees the chunks, the context of where they came from is lost.
- webWorkerTsConfig: workers must be imported via a root relative path (e.g.`app/search/search.worker`) instead of a relative path (`/search.worker`) because of the same reason as above.
- loadChildren string syntax: doesn't work because rollup cannot follow the imports.
* feat(@angular-devkit/core): update schema to support new i18n options
"projects": {
"my-app": {
"projectType": "application",
"schematics": {},
"root": "",
"i18n": {
"sourceLocale": "en-US",
"locales": {
"fr": "src/locale/messages.fr.xlf"
}
},
"sourceRoot": "src",
...
}
}
* feat(@angular-devkit/build-angular): add new i18n options to browser and server builders
With this change we add `translateLocales` as new options for i18n in browser and server builders.
We also deprecate the following options;
* i18nLocale
* i18nFormat
* i18nFile
* feat(@angular-devkit/build-angular): deprecate `i18nFormat` and `i18nLocale` options of `extract-i18n` builder
Option `i18nFormat` has been deprecated in favor of `format` and `i18nLocale` option has been deprecated in favor of the `sourceLocale` sub option of the `i18n` project level option.
* feat(@angular/cli): add alias of `i18n-extract` for `x18n` command
* refactor: rename `translateLocales` to `localize`
This is currently only supported when performing a differential loading build (no watch mode). This will eventually be expanded to cover watch mode and non-differential loading builds.
