When not using the Angular CLI, the Babel-based Ivy linker is also required to successfully build an application. A section describing the setup of the linker in addition to the Angular compiler plugin has now been included with links to the AIO documentation and the babel-loader for additional information.
With the Angular CLI currently being a CommonJS package, this change 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.
Type only static import statements for `@angular/compiler-cli` are also now used since 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.
BREAKING CHANGE:
Applications directly using the `webpack-cli` and not the Angular CLI to build must set the environment variable `DISABLE_V8_COMPILE_CACHE=1`. The `@ngtools/webpack` package now uses dynamic imports to provide support for the ESM `@angular/compiler-cli` package. The `v8-compile-cache` package used by the `webpack-cli` does not currently support dynamic import expressions and will cause builds to fail if the environment variable is not specified. Applications using the Angular CLI are not affected by this limitation.
rules_nodejs 4 requires that a package_name property be specified within a ts_library rule for the output to be linked into the package repository. Failing to add the property can cause test failures due to unresolved packages.
The `no-useless-escape` eslint rule has now been enabled which removes unneeded characters and complexity from string literals and regular expressions. All files that were in violation of this rule have also been corrected.
The internal TypeScript path mapping Webpack resolver plugin is used to adjust module resolution during builds via the TypeScript configuration `paths` option. Prior to a build, the `paths` option is now preprocessed to limit the amount of analysis that is needed within each individual module resolution attempt during a build. Since module resolution attempts can occur frequently during a build, this change offers the potential to reduce the total cost of module resolution especially for applications with a large amount of configured path mappings.
The types used from the `enhanced-resolve` package are available from the `webpack` package and the `getInnerRequest` helper function used in the TypeScript paths resolver plugin is not actually needed. Webpack's `AliasPlugin` which has similar behavior also does not use the `getInnerRequest` helper function.
