TypeScript files had the potential to be processed twice by the build optimizer. This did not affect the output code but could lead to longer production build times. The build optimizer is now configured in one centralized location for both TypeScript and JavaScript files. The Webpack configuration partial for TypeScript support is also reduced to one common function for both AOT and JIT as a result.
A new build option named `inlineStyleLanguage` has been introduced that will allow a project to define the stylesheet language used in an application's inline component styles. Inline component styles are styles defined via the `styles` property within the Angular `Component` decorator. Both JIT and AOT mode are supported. However, JIT mode requires that inline styles only be string literals (compile-time partial evaluation is not supported in JIT mode). Currently supported language options are: `CSS` (default), `Sass`, `SCSS`, and `Less`. If the option is not specified, `CSS` will be used and enables existing projects to continue to function as expected.
With this change we update ajv to version 8
BREAKING CHANGE: support for JSON Schema draft-04 and draft-06 is removed. If you have schemas using the `id` keyword replace them with `$id`. For an interim period we will auto rename any top level `id` keyword to `$id`.
**NB**: This change only effects schematics and builders authors.
The internal Webpack configuration now includes support for style rules with MIME type conditions. This allows the data URIs generated for inline component CSS styles by the Angular Webpack plugin to be processed with the same loaders as file based styles.
With this change we configure new libraries to be published using Ivy partial compilation instead of the deprecated View Engine rendering engine, we also remove several view engine specific `angularCompilerOptions`.
New libraries can be published using this format, as they are not depend upon by View Engine libraries or application.
Webpack 5 now includes web worker support. However, the structure of the URL within the `Worker` constructor must be in a specific format.
Before: `new Worker('./app.worker', ...)`
After: `new Worker(new URL('./app.worker', import.meta.url), ...)`
With this change Webpack 5 is now used by the Angular tooling to build applications. Webpack 4 usage and support has been removed.
No project level configuration changes are required to take advantage of the upgraded Webpack version when using the official Angular builders.
Custom builders based on this package that use the experimental programmatic APIs may need to be updated to become compatible with Webpack 5.
BREAKING CHANGE: Webpack 5 lazy loaded file name changes
Webpack 5 generates similar but differently named files for lazy loaded JavaScript files in development configurations (when the `namedChunks` option is enabled).
For the majority of users this change should have no effect on the application and/or build process. Production builds should also not be affected as the `namedChunks` option is disabled by default in production configurations.
However, if a project's post-build process makes assumptions as to the file names then adjustments may need to be made to account for the new naming paradigm.
Such post-build processes could include custom file transformations after the build, integration into service-side frameworks, or deployment procedures.
Example development file name change: `lazy-lazy-module.js` --> `src_app_lazy_lazy_module_ts.js`
BREAKING CHANGE: Webpack 5 web worker support
Webpack 5 now includes web worker support. However, the structure of the URL within the `Worker` constructor must be in a specific format that differs from the current requirement.
Web worker usage should be updated as shown below (where `./app.worker` should be replaced with the actual worker name):
Before: `new Worker('./app.worker', ...)`
After: `new Worker(new URL('./app.worker', import.meta.url), ...)`
BREAKING CHANGE:
Removal of deprecated browser and server command options.
- `i18nFile`, use `locales` object in the project metadata instead.
- `i18nFormat`, No longer needed as the format will be determined automatically.
- `i18nLocale`, use `localize` option instead.
BREAKING CHANGE: Removal of View Engine support from application builds
With the removal of the deprecated View Engine compiler in Angular version 12 for applications, Ivy-based compilation will always be used when building an application.
The default behavior for applications is to use the Ivy compiler when building and no changes are required for these applications.
For applications that have opted-out of Ivy, a warning will be shown and an Ivy-based build will be attempted. If the build fails,
the application may need to be updated to become Ivy compatible.
Deprecated packages that may have been included in a project by the tooling are now ignored when validating an update. This change removes the need to use the `--force` option in a situation where the later migrations will remove and cleanup the deprecated packages.
With the move to refactor and centralize the update logic, the schematics wrapper context needs to be updated to create an exception for the new location of the update schematic.
BREAKING CHANGE: Removal of View Engine support from i18n extraction
With the removal of the deprecated View Engine compiler in Angular version 12 for applications, the `ng extract-i18n` command will now always use the Ivy compiler.
The `--ivy` option has also been removed as Ivy-based extraction is always enabled.
The default behavior for applications is to use the Ivy compiler for building/extraction and no changes are required for these applications.
For applications that have opted-out of Ivy, a warning will be shown and Ivy-based extraction will be attempted. If the extraction fails,
the application may need to be updated to become Ivy compatible.
Previously, `addSymbolToNgModuleMetadata()` assumed that the added
symbol would not span multiple lines. In most cases, the added symbol is
a single word, so this assumption was correct. In some cases, however,
we might want to add a mutli-line string, such as a static method of an
`@NgModule`:
```ts
imports: [
SomeModule.staticMethod({
prop1: 'val1',
prop2: 'val2'
})
]
```
This commit allows `addSymbolToNgModuleMetadata()` to correctly handle
multi-line strings by ensuring that added metadata symbols are always
put on a new line (even if the array is empty) and each line in the
string is indented as necessary.
Windows CI is failing when trying to use the common test cleanup routine for the `generate/component/component-path-case` E2E test. This fix manually removes the newly created directory within the test.
BREAKING CHANGE:
The `ng add` command will now ask the user to confirm the package and version prior to installing and executing an uninstalled package.
This new behavior allows a user to abort the action if the version selected is not appropriate or if a typo occurred on the command line and an incorrect package would be installed.
A `--skip-confirmation` option has been added to skip the prompt and directly install and execute the package. This option is useful in CI and non-TTY scenarios such as automated scripts.
The plugin was only used when the `NG_BUILD_PROFILING` environment variable was used. The environment variable also enabled the Webpack builtin `ProfilingPlugin` which is retained.
The builtin plugin provides a chrome events JSON output which can be loaded in Chrome DevTools and allows for graphical timeline views of the build.
The `speed-measure-plugin` is also currently incompatible with Webpack 5 which would prevent the CLI profiling support from working with Webpack 5.
