When using the experimental esbuild-based browser application builder with the `--stats-json`
option, all referenced CSS resources will now use paths relative to the workspace root within
the output JSON file. Previously, the resource paths within the stats JSON file were absolute
and were inconsistent with the other JavaScript and CSS paths within the file. CSS resources
include files that have been referenced in a bundled stylesheet `url()` such as images or fonts.
With this change we add an `exclude` option to the Karma builder to provide a way to exclude certain specs from the compilation.
This is useful, when having integration, e2e and unit tests with the same suffix.
Closes#24472
When using the experimental esbuild-based browser application builder, the `--extract-licenses`
option will now generate an output licenses file when enabled. This option extracts license
information for each node module package included in the output files of the built code. This
includes JavaScript and CSS output files. The esbuild metafile information generated during the
bundling steps is used as the source of information regarding what input files where included and
where they are located. A path segment of `node_modules` is used to indicate that a file belongs
to a package and its license should be include in the output licenses file.
The package name and license field are extracted from the `package.json` file for the
package. If a license file (e.g., `LICENSE`) is present in the root of the package, it
will also be included in the output licenses file. Custom licenses as defined by the recommended
npm custom license text (`SEE LICENSE IN <filename>`) will also be extracted and included in the
output license file. For additional information regarding the license field in a `package.json`,
see https://docs.npmjs.com/cli/v9/configuring-npm/package-json#license.
Within the experimental esbuild-based browser application builder, the internal paths for angular
component stylesheets were being displayed in the esbuild metafile with a duplicate namespace prefix.
This had no functional difference to the build output but it did make the paths in the metafile
unnecessarily long and potentially confusing. The paths now only contain the prefix a single time.
This also has the benefit of reducing the length of the filter regular expressions for the stylesheet
plugins used for Angular component styles by not needing to match the namespace in the path in addition
to the namespace option.
When performing a release via the dev-infra `ng-dev` tooling, the release
builds for the packages that will be published are now performed using bazel.
Prior to this, the release builds were performed using a custom build script
that programmatically invoked TypeScript APIs. The Bazel build and discovery
process for the releasable packages is performed by a script that is based on
the scripts from components and framework repositories. Several small modifications
were performed to match the behavior and structure of the cli repository:
* Use of `packages` as the source root in the bazel query
* Use of `pkg_npm` rule in the bazel query
* Partial transition to native Node.js `fs` APIs instead of `shelljs`
* Directory creation per package when copying output (supports multiple package scopes)
* Copying of archives (tgz) for each package
The snapshot and local build capabilities are not modified as part of this change
but will be merged in a followup as part of a larger transition to use bazel
throughout the package build process.
This commits add a schematic to generate Karma and Browserlist files which since version 15 are no longer generated by default. This schematic should be used to generate these files when further customisation is needed.
Usage
```
ng generate config karma
ng generate config browserlist
```
Closes#24294
When using the esbuild-based browser application builder, the Sass compiler will attempt to
resolve any relative load paths from the current working directory. However, the load paths
from the `angular.json` file should always be relative to the location of the `angular.json`
which is considered the workspace root. While the current working directory is typically
also the workspace root, it is not required nor always the same. To resolve this potential
mismatch, the load paths are now resolved from the workspace root prior to being passed to
the Sass compiler.
Prior to this change esbuild errors during the javascript optimization phase in the Webpack builder were not being formatting properly which caused meaningful information to be lost.
Closes#24457
When using the experimental esbuild-based browser application builder, the `--stats-json`
option can now be used to create an esbuild metafile named `stats.json` in the output
directory of the application. The metafile contents will contain information about the
application JavaScript, global stylesheets, and the component stylesheets used by the
Angular compiler. While the `--stats-json` option controls the output of the file onto
the filesystem, the metafile data is internally always created to support the future
integration of the bundle budget and console build stat output capabilities.
The metafile format follows the structure of the esbuild metafile format. Information
regarding the file format can be found here: https://esbuild.github.io/api/#metafile
When using the experimental esbuild-based browser application builder, async generator class
methods will now be transformed to a downlevel form based on promise objects. This transformation
is performed by babel and was previously (and still is) performed on async generator functions.
This transformation is necessary to ensure Zone.js can hook async code via the Promise objects.
Only async generator transformation is currently performed via babel as esbuild can handle all other
native async syntax that requires transformation for Zone.js support.
When using the experimental esbuild-based browser application builder, the `ngDevMode` global
runtime variable was unintentionally always being set to false due to a previous bug fix that stopped
the variable from being replaced with the value of true when script optimizations were disabled.
By doing so, the fix caused the imported compiler-cli `GLOBAL_DEFS_FOR_TERSER_WITH_AOT` constant
to take precedence which contains an `ngDevMode` value of false. To prevent this situation for
development builds where a non-false `ngDevMode` is helpful to surface potential runtime problems,
`GLOBAL_DEFS_FOR_TERSER_WITH_AOT` will no longer change the value of `ngDevMode`. This fix does not
have any effect on production builds since `ngDevMode` would have been set to false regardless.
When using the experimental esbuild-based browser application builder, the `inlineStyleLanguage`
option and the usage of inline Angular component styles that contain Sass are now supported. The
`inlineStyleLanguage` option values of `css`, `sass`, and `scss` can be used and will behave as
they would with the default Webpack-based builder. The less stylesheet preprocessor is not yet
supported in general with the esbuild-based builder. However, when support is added for less,
the `inlineStyleLanguage` option will also be able to be used with the `less` option value.
This commits enables `@babel/plugin-proposal-private-methods` when targeting Safari <=v15 as this is needed to handle private class methods when using `@babel/plugin-proposal-class-properties`.
Closes#24411
This commit changes how we set the `LOCALE_ID` when using the `localize` option
- We now include the locale setting snippet only in the main bundle.
- We use `globalThis` to set the the value globally and be accessible across module boundaries. This is important as in some causes such as when using MF `@angular/core` can be located in a bundles others than `main` and `vendor`.
Sass source maps
This commits enables `sourceMapIncludeSources` when using the modern Sass API so that sources are included in generated
source map.
Closes#24394
These async methods are a replacement for the Observable based `runSchematicAsync` and `runExternalSchematicAsync` methods.
DEPRECATED:
The Observable based `SchematicTestRunner.runSchematicAsync` and `SchematicTestRunner.runExternalSchematicAsync` method have been deprecated in favor of the Promise based `SchematicTestRunner.runSchematic` and `SchematicTestRunner.runExternalSchematic`.
When using the experimental esbuild-based browser application builder, the JavaScript
transformation workers will now only receive the explicit options expected. Previously,
additional Angular compiler plugin options could have been serialized and sent as well.
While these would be unused, there was no need to serialize/deserialize these option values.
When using the experimental esbuild-based browser application builder, the `preserveSymlinks`
option will now default to the value of the Node.js `--preserve-symlinks` argument. This removes
the need to manually specify the option in two places if executing the build manually with Node.js
or via the `NODE_OPTIONS` environment variable. This behavior mimics that of the default Webpack-based
builder.
To provide a workaround for a Safari bug involving class fields and variable scoping,
the esbuild-based browser application builder will now downlevel class fields if Safari
(desktop or iOS) v15.x or earlier is within the target browsers for an application.
This is an esbuild variant of the fix for the Webpack-based builder. For more details
regarding the issue, please see: #24357
The conversion of browserslist targets to esbuild targets has been updated to reflect additions
to esbuild. Additional browsers are now supported and the major/minor versions have been normalized.
The later of which ensures that `.0` major versions are not misinterpreted as ranges rather than
specific versions.
The Angular compiler is dependent on static fields being attached to
user-defined classes. e.g. `static ecmp = defineComponent`.
These static fields sometimes rely on variables from outside of the
class. e.g. the Angular compiler generates constants for content
projection that are then accessed in the static field initializer.
Surprisingly such access to these variables may break in Safari <=v15
when a page is loaded without devtools open. The bug (already solved in
v16 of Safari)- is very subtle, hard to re-reproduce but basically
variable scope tracking is broken. This bug is triggered by additional
parenthesis in the initializer expression. See:
https://bugs.webkit.org/show_bug.cgi?id=236843.
The TypeScript compiler may generate such additional parenthesis when
it tries to adjust the `this` context when invoking methods, such as for
defining animations in the `ecmp` definition.
More details can be found here:
https://github.com/angular/angular-cli/issues/24355#issuecomment-1333477033
To ensure Angular applications are not subject to this bug when
targeting Safari <=v15. v15 Safari, both for iOS and Mac is still part of
the default CLI browserslist with `last 2 Safari majors` (at time of
writing).
Note that it is important that the Babel plugin properly handles the
downleveling of static block-defined members. TypeScript will transform
static fields, like `static ecmp` into `static { this.ecmp = X }` when
`useDefineForClassFields = false` (which is the case for CLI apps). The
class properties plugin from Babel seems to handle this in an acceptable
way. Unlike actual static fields, Babel will not use helpers like
`defineProperty` for such extracted static blocks though. e.g.
See repro: https://gist.github.com/devversion/dec0dea26e348c509921bf62079b60be
```js
class Test {
x = true;
static b = true;
static {
this.a = true;
}
}
// into
class X {
constructor() {
_defineProperty(this, "x", true);
}
}
_defineProperty(X, "b", true);
X.a = true;
```
note that in practice TypeScript with `useDefineForClassFields = false`
will put non-static members into the constructor as normal assignments
regardless- so there would be no change by the Babel plugin.
Fixes#24355.
When optimization is enabled with the `@angular-devkit/build-angular:browser` builder, terser
is used as a second phase optimizer. The terser configuration previously set its `ecma` option
to `es2020` due to all officially supported browsers supporting the version. However, it is
possible to add browsers to the browserslist configuration that are not officially supported
that still may work but do not support es2020 syntax features. By setting the terser `ecma`
option to `es2015`, terser will not turn existing syntax into newer syntax features that might
be unsupported. Terser will also not downlevel any code based on this option.
Fixes#24347
Similar to errors messages we now hide webpack paths in warnings to reduce clutter.
Before
```
./src/styles.scss.webpack[javascript/auto]!=!./node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[6].rules[0].oneOf[0].use[1]!./node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[6].rules[0].oneOf[0].use[2]!./node_modules/resolve-url-loader/index.js??ruleSet[1].rules[6].rules[1].use[0]!./node_modules/sass-loader/dist/cjs.js??ruleSet[1].rules[6].rules[1].use[1]!./src/styles.scss?ngGlobalStyle - Warning: Module Warning (from ./node_modules/sass-loader/dist/cjs.js):
Deprecation $weight: Passing a number without unit % (60) is deprecated.
To preserve current behavior: $weight * 1%
More info: https://sass-lang.com/d/function-units
@material/slider/_slider-theme.scss 77:5 @use
node_modules/@angular/material/slider/_slider-theme.scss 3:1 @use
node_modules/@angular/material/core/density/private/_all-density.scss 25:1 @forward
@angular/_index.scss 18:1 @use
src/styles.scss 2:1 root stylesheet
```
After
```
./src/styles.scss - Warning: Module Warning (from ./node_modules/sass-loader/dist/cjs.js):
Deprecation $weight: Passing a number without unit % (60) is deprecated.
To preserve current behavior: $weight * 1%
More info: https://sass-lang.com/d/function-units
@material/slider/_slider-theme.scss 77:5 @use
node_modules/@angular/material/slider/_slider-theme.scss 3:1 @use
node_modules/@angular/material/core/density/private/_all-density.scss 25:1 @forward
@angular/_index.scss 18:1 @use
src/styles.scss 2:1 root stylesheet
```
When rebasing URLs found within Sass files (sass/scss), the previous regular expression
based searching has been replaced with a lexer that scans the Sass files for CSS url()
functions and extracts URL values. This change allows for more accurate discovery of
URLs as well as reducing the amount of content traversals per file. The lexer logic
is based on CSS Syntax Module Level 3 (https://www.w3.org/TR/css-syntax-3/).
The creation of the esbuild Angular plugin's Angular compilation has now been consolidated in a separate
class. This refactor reduces the amount of code within the plugin's main start function as well as centralizing
initialization, analysis, and source file emitting for the Angular build process.
When resolving Sass imports in the experimental esbuild-based browser application builder's Sass plugin,
previously imported modules are used as the base for resolution attempts to workaround the lack of the
importer file provided by Sass. When attempting to resolve a deep import into a package (including the
potential Sass index files), these previously imported modules also need to be checked. This is
particularly relevant when using the Yarn PnP or pnpm package managers which enforce strict dependency
resolution.
Fixes#24271
When using the experimental esbuild-based browser application builder, the JavaScript transformation
steps of the build process will now be performed within a worker pool to allow for the steps to be
executed in parallel when possible. This also moves the steps off of the main thread which provides
more time for the build orchestration and esbuild integration code to execute.