The basic suite of E2E tests are now run against the newly introduced experimental esbuild-based builder (`browser-esbuild`).
Several tests are currently ignored based on the current feature set of the builder.
An experimental browser application builder (`browser-esbuild`) has been introduced that leverages esbuild as the bundler.
This new builder is compatible with options of the current browser application builder (`browser`) and can be enabled
for experimentation purposes by replacing the `builder` field of `@angular-devkit/build-angular:browser` from an existing
project to `@angular-devkit/build-angular:browser-esbuild`. The builder will generate an ESM-based application and
provides support for ES2015+ compatible output with ES2020 as the default.
This builder is considered experimental and is not recommended for production applications.
Currently not all `browser` builder options and capabilities are supported with this experimental builder.
Additional support for these options may be added in the future.
The following options and capabilities are not currently supported:
* Stylesheet Preprocessors (only CSS styles are supported)
* Angular JIT mode (only AOT is supported)
* Localization [`localize`]
* Watch and dev-server modes [`watch`, `poll`, etc.]
* File replacements [`fileReplacements`]
* License text extraction [`extractLicenses`]
* Bundle budgets [`budgets`]
* Global scripts [`scripts`]
* Build stats JSON output [`statsJson`]
* Deploy URL [`deployURL`]
* CommonJS module warnings (no warnings will be generated for CommonJS package usage)
* Web Workers
* Service workers [`serviceWorker`, `ngswConfigPath`]
Several imported types and values from `@angular-devkit/core` could be removed while still
maintaining the same functionality. This further reduces the schematics direct dependence
on the `@angular-devkit/core` package.
By using the `strings` re-export from `@angular-devkit/schematics` instead of from `@angular-devkit/core`,
the number of imports from `@angular-devkit/core` has been reduced and lowers the direct dependency count
for many of the individual schematics.
The string helpers are predominantly used within schematics that will already depend and import from
the `@angular-devkit/schematics` package. By re-exporting from `@angular-devkit/schematics`, the need
to directly depend and import `@angular-devkit/core` within a schematic can be reduced and in many
cases eliminated.
The `glob`-based check when adding the sourcemap support packages to the karma setup was incorrectly
skipping the files due to Windows pathing issues. The `glob`-based check, however, is unneeded due
to the already present `require.resolve` checks for the sourcemap support packages which will
throw if the packages are not present.
This is not needed as inputs are typed checked to be `JsonValue`. With this change we get a step closer to remove `fast-json-stable-stringify` dependency.
To enable bash and zsh real-time type-ahead autocompletion, copy and paste the generated script by the `ng completion` command to your `.bashrc`, `.bash_profile`, `.zshrc` or `.zsh_profile`.
Closes#11043
This changes removes most of the usage of `getWorkspaceRaw` in the Angular CLI. This is needed to eventually drop the direct dependency on `jsonc-parser`.
With this change we add a Yargs middleware that normalizes non Array options when the argument has been provided multiple times.
By default, when an option is non array and it is provided multiple times in the command line, yargs
will not override it's value but instead it will be changed to an array unless `duplicate-arguments-array` is disabled.
But this option also have an effect on real array options which isn't desired.
See: https://github.com/yargs/yargs-parser/pull/163#issuecomment-516566614Closes#22956
Infrastructure has been added to the schematics runtime within the `@angular/cli`
package to allow schematics executed via the Angular CLI to have access upcoming
built-in modules. These built-in modules will be imported/required using the
`schematics:` scheme similar to the Node.js `node:` scheme available for Node.js
built-in modules. No built-in modules exist yet but will be added in the future.
Schematics must be executed via the Angular CLI Schematics runtime's custom VM context
to use the upcoming built-in modules. All first-party Angular schematics have been
executed in this manner for several major versions. Third-party schematics can now
opt-in to the behavior by enabling the `encapsulation` option within a schematic collection
JSON file.
The `_resolveReferenceString` abstract method of the `FileSystemEngineHostBase` class now has a third parameter
that provides the collection description of the schematic currently being resolved. This allows the resolver to
use any fields/options present within the collection description to adjust the resolution of the schematic. The
`encapsulation` optional field is also added to the `FileSystemCollectionDescription` type which will in the future
allow control of the `@angular/cli` VM context wrapping on an individual schematic collection basis.
