With the removal of support for the string form of `loadChildren` within the Angular router, the usage of `System.import` has also been removal from `@angular/core`. This removal allows for the additional removal of all workarounds within the Angular CLI due to the `System.import` usage. Webpack's deprecated support for `System.import` was previously required to be enabled which resulted in warnings that then needed to be suppressed. A Webpack context dependency replacement was also previously required to prevent Webpack from failing due to the otherwise unknown behavior of the `System.import` call. All of these workarounds have now been removed.
This change uses the `@ampproject/remapping` package to merge sourcemaps generated from the customized babel loader used to perform the partial compilation linking in applications as well as other optimization and downleveling transformations. This provides more accurate output mapppings as well as improved performance and lower memory usage when source maps are enabled within a build.
The regular expressions based checks for TypeScript and JavaScript files used by Webpack module rules have been updated to include all current extension variations.
JavaScript files can be either `.js`, `.mjs`, or `.cjs`. TypeScript files as of the upcoming version 4.5 can be either `.ts`, `.mts`, or `.cts`.
Also while not officially supported by Angular, the TypeScript compiler can attempt to process any of the previous extensions with an `x` suffix which indicates a JSX/TSX file.
BREAKING CHANGE: With this change a number of deprecated dev-server builder options which proxied to the browser builder have been removed. These options should be configured in the browser builder instead.
The removed options are:
- `aot`
- `sourceMap`
- `deployUrl`
- `baseHref`
- `vendorChunk`
- `commonChunk`
- `optimization`
- `progress`
This is a follow-up to fb210e5b747ce0351dd9ee7d482770b9cfa71133 which
added support for the ESM-variant of the `@angular/localize` package,
and also prepared for the `tools/` secondary entry-point we will expose
as of v13.
Unfortunately this change currently does not pass-through the ESM-loaded
plugin creators as the option (which is passed to the Babel plugin) is
incorrect. This was hidden due to a type cast. This commit fixes the
issue and also ensures TS would complain in the future if the option
names differ.
A Babel webpack loader specific `@angular/localize` package `Diagnostics` object is now created that is optimized for the diagnostics reporting case. This removes the need to manually create and patch an instance of a Diagnostics object. Future work will potentially allow a reporter to be passed directly to the translation plugins to remove the need to create a new object entirely.
Previously, the search for a locale's data when using i18n was performed by a series of file system accesses that searched through the `@angular/common` package. The search is now conducted via Node.js module resolution which has several advantages. The internal structure of the package is no longer assumed and allows the `@angular/common` package to change its internal implementation without affecting the locale data search. File extensions of the locale data files are also not hard-coded as only the name of the locale data is needed to perform a search. There are also less direct file system access calls and the search can leverage whatever internal caching Node.js performs during module resolution.
With the Angular CLI currently being a CommonJS package, this change uses a dynamic import to load `@angular/localize` which may be ESM. CommonJS code can load ESM code via a dynamic import. Unfortunately, TypeScript will currently, unconditionally downlevel dynamic import into a require call. require calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import.
With Angular Package Format v13, we will be using a more recent version of rollup. Rollup
always suffixed exports to avoid collisions, but with the most recent version, the order
has changed slightly changed. e.g. previously for `@angular/core`, there were two instances
of the `ViewEncapsulation` enum part of the `fesm` bundle. The second instance of the enum
orginated from the compiler <--> core facade and it got renamed to avoid conflicts with the
actual declaration of `ViewEncapsulation`. Now this has changed, and the first export is
being renamed instead. This now breaks at runtime because the first export is being incorrectly
transformed by the adjust enum plugin of `build-angular`. The plugin always had this problem
of incorrectly transforming the enums, but it never surfaced because only the face enum has been
transformed (which is not used at runtime). e.g.
consider the following input in `core.mjs`:
```
var ViewEncapsulation$1;
(function (ViewEncapsulation) {
ViewEncapsulation[ViewEncapsulation["Emulated"] = 0] = "Emulated";
})(ViewEncapsulation$1 || (ViewEncapsulation$1 = {}));
```
this is transformed into:
```
var ViewEncapsulation$1 = /*#__PURE__*/(() => {
ViewEncapsulation$1 = ViewEncapsulation$1 || {};
ViewEncapsulation[ViewEncapsulation["Emulated"] = 0] = "Emulated";
}());
```
Note how the enum assignment for `Emulated` incorrectly still uses the non-suffixed
identifier that previously was part of the callee wrapper function.
The `proxyConfig` option now supports loading ESM configuration files in addition to JSON and CommonJS files. ESM files (such as those ending with `.mjs`) must provide a default export with the configuration object.
For example, a `proxy.config.mjs` containing the follow is now possible:
```
export default { "/api/*": { "target": "http://127.0.0.1:5001" } };
```
Closes#21623
Absolute import paths, especially on Windows, must be `file://` URLs when using ESM. Otherwise, Windows drive letters (e.g., `C:`) would be interpreted as a protocol instead of a drive letter when performing the import.
With the Angular CLI currently being a CommonJS package, this change uses a dynamic import to load `@angular/service-worker/config` which may be ESM. CommonJS code can load ESM code via a dynamic import. Unfortunately, TypeScript will currently, unconditionally downlevel dynamic import into a require call. require calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import.
This is a followup PR for #21771 that addresses partial compilation linker usage.
With the Angular CLI currently being a CommonJS package, this change uses a dynamic import to load `@angular/compiler-cli/linker[/babel]` which may be ESM. CommonJS code can load ESM code via a dynamic import. Unfortunately, TypeScript will currently, unconditionally downlevel dynamic import into a require call. require calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import.
In the event that the Angular CLI is executed on a platform that does not yet have native support for esbuild, the WASM-based variant of esbuild will now be used. If the first attempt to optimize a file fails to execute the native variant of esbuild, future executions will instead use the WASM-based variant instead which will execute regardless of the native platform. The WASM-based variant, unfortunately, can be significantly slower than the native version (some cases can be several times slower). For install time concerns regarding the esbuild post-install step, esbuild is now listed as an optional dependency which will allow the post-install step to fail but allow the full npm install to pass. This install scenario should only occur in the event that the esbuild native binary cannot be installed or is otherwise unavailable.
This uses a dynamic import to load `@angular/compiler-cli` which may be ESM. CommonJS code can load ESM code via a dynamic import. Unfortunately, TypeScript will currently, unconditionally downlevel dynamic import into a require call. require calls cannot load ESM code and will result in a runtime error. To workaround this, a Function constructor is used to prevent TypeScript from changing the dynamic import. Once TypeScript provides support for keeping the dynamic import this workaround can be dropped and replaced with a standard dynamic import.
Partial Webpack configuration generators are used to create the various aspects of the final Webpack configuration for build, testing, and serving. They previously could only be synchronous but may need to perform asynchronous actions to setup the Webpack configuration in the future. This is particularly relevant as the CLI transitions from CommonJS to ESM wherein synchronous require calls need to be replaced with asynchronous dynamic imports. For dynamic imports to be successfully used the configuration generators need to support asynchronous operations.
The `@angular/compiler-cli` is used as a peer dependency and has the potential to not be present. As a result static imports should only be used for types and value imports should be dynamic so that they can be guarded in the event of package absence. There are still several instances of static imports for values but these will be corrected in follow-ups.
Polyfill related packages should not be downlevelled due to the nature of their code which may need to perform feature testing or leverage native capabilities to extract browser support information necessary to properly polyfill a given browser. In the case of `web-streams-polyfill`, it leverages the `%AsyncIteratorPrototype%`, when available, to fully polyfill its stream implementations. To access `%AsyncIteratorPrototype%`, a native async generator is needed and therefore the code present in the package cannot have this case of a native async generator downlevelled. `core-js` is also excluded for similar (and additional reasons).
The browser targets provided by `browserslist` have several differences than what `esbuild` expects for the Safari browsers. The first is that the iOS Safari is named `ios_saf` within browserslist and `ios` by esbuild. The former is now converted to the later when generating the target list for esbuild. The second difference is that `browserslist` supports a `TP` (Technology Preview) version for Safari but esbuild expects a numeric value for all versions. Since a TP version of Safari is assumed to be the latest unreleased version and as a result supports all currently known features, a high version number (999) is used as a replacement when generating the target list for esbuild.
