Previously, we failed the compilation when the specified patterns did not match any spec file. This breaks the case were users configure Karma to not fail on empty test suit.
Closes#24644
This commit updates changes the way polyfills and runtime are loaded from modules to scripts. This is required as otherwise Jasmine will be loaded prior to Zone.js which causes clock patching not to work.
Closes#24651
When using the experimental esbuild-based browser application builder, the `aot` build option
can now be set to `false` to enable JIT compilation mode. The JIT mode compilation operates
in a similar fashion to the Webpack-based builder in JIT mode. All external Component stylesheet
and template references are converted to static import statements and then the content is bundled
as text. All inline styles are also processed in this way as well to support inline style languages
such as Sass. This approach also has the advantage of minimizing the processing necessary during rebuilds.
In JIT watch mode, TypeScript code does not need to be reprocessed if only an external stylesheet
or template is changed.
* test: run legacy-cli e2e tests via bazel
* fixup! test: run legacy-cli e2e tests via bazel
* fixup! test: run legacy-cli e2e tests via bazel
* fixup! test: run legacy-cli e2e tests via bazel
When using Sass with the experimental esbuild-based browser application builder, bare imports
without a path segment that were available via included paths but also happen to be a node module
could cause an exception. An example of such an import would be `@import "globals";`. The deep
import node module logic would previously attempt to join an undefined path segment to the resolved
path for the `globals` package which would raise a argument type exception. This case has now been
fixed by only joining if there is actually a path segment present such as `@import "globals/x"`.
With this fix in place, the node module case can then continue and if no stylesheet is found, the
include paths will then be searched.
Due to the update of the experimental esbuild-based browser application builder to use esbuild 0.17,
the watch mode has been changed to use the new incremental API. The previous API has been removed
from esbuild. The new API involves creating a build context object that can then be used to perform
rebuilds of the configured application bundler as needed. All watch mode usage has been updated to
use this new approach. An effort was made to minimize the amount of changes made to support this API
update and limit the changeset. However, further refactoring will be possible as additional capabilities
are added in the future.
esbuild API reference: https://esbuild.github.io/api/#rebuild
When using the experimental esbuild-based browser application builder and an exception is thrown
during the initial build, the process may hang indefinitely due to the Sass worker pool not
shutting down fully. This does not happen for rebuilds after the initial. To remedy this
situation, The initial build is now wrapped in a try block to ensure that a full shutdown
of the Sass worker pool occurs.
When using the experimental esbuild-based browser application builder, input files
for the build will now be checked to determine if they are non-ESM modules. This
behavior is comparable to the existing behavior within the default Webpack-based browser.
Warnings will now be issued for any non-ESM modules (for example, CommonJS or UMD) when
script optimizations are enabled (typically production builds). ESM files can be tree-
shaken and otherwise optimized in ways that CommonJS files cannot which allows for
more optimized and smaller output bundle files.
If any allowed dependencies are provided via the `allowedCommonJsDependencies`
option, both the direct import and any deep imports of the dependency will be ignored
during the checks and no diagnostic will be generated for the dependency.
The i18n inlining worker code was previously imported in several locations to allow
reuse of the options object used to configure the worker. To prevent the worker
code from being used outside of an actual worker, the options object definition is
now located in a separate file and imported in both the worker and any other files
that need to use the inlining options.
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.
