With the `application` builder already within the new `@angular/build` package,
the `extract-i18n` builder with application builder support is now also contained within this package.
Only the application builder aspects of `extract-i18n` have been moved.
The compatibility builder `browser-esbuild` is not supported with `@angular/build:extract-i18n`.
The existing `extract-i18n` builder found within `@angular-devkit/build-angular` should continue to be used for both the
Webpack-based `browser` builder and the esbuild-based compatibility `browser-esbuild`
builder. To maintain backwards compatibility, the existing `@angular-devkit/build-angular:extract-i18n`
builder continues to support builders it has previously.
No change to existing applications is required.
The `@angular/build` package has been introduced to house the esbuild/Vite-based
build system that was newly introduced as stable in v17. The existing
`@angular-devkit/build-angular` package will continue to contain the Webpack-based
build system and to ensure backwards compatibility it will also provide aliases
for the esbuild/Vite-based build system. The changes here are the first stage
of the builder transition and moves the `application` builder into the new package.
The application builder can now be accessed when this package is installed directly
via `@angular/build:application`.
No changes are required for existing projects.
This is a new `@angular-devkit/build-angular:web-test-runner` builder which invokes Web Test Runner to execute unit tests in a real browser.
The implementation calls `application` builder under the hood with some option overrides build the application to a temporary directory and then runs Web Test Runner on the output. This set up is still minimal, but sufficient to run and pass tests in the generated `ng new` application.
The `schema.json` file is directly copied from the `karma` builder, since this is intended to serve as a migration target for users coming from Karma. Most of the options don't actually work yet, which is logged when they are used.
The most interesting part of this change is configuring Jasmine to execute in Web Test Runner. This is done through the `testRunnerHtml` option which allows us to control the HTML page tests are executed on. We use `test_page.html` which very carefully controls the loading process. I opted to make a single `<script type="module">` which dynamic imports all the relevant pieces so the ordering can be directly controlled more easily. This is better than trying to manage multiple `<script>` tags and pass data between them. Ideally everything would be bundled into a single entry point, however this is not feasible due to the way that ordering requirements do not align with typical `import` structure. Jasmine must come before polyfills which must come before the runner which invokes user code. In an ideal world, this ordering relationship would be represented in `import` statements, but this is not practically feasible because Angular CLI doesn't own all the files (`./polyfills.js` is user-defined) and Jasmine's loading must be split into two places so Zone.js can properly patch it.
`jasmine_runner.js` serves the purpose of executing Jasmine tests and reporting their results to Web Test Runner. I tried to write `jasmine_runner.js` in TypeScript and compile it with a `ts_library`. Unfortunately I don't think this is feasible because it needs to import `@web/test-runner-core` at runtime. This dependency has some code generated at runtime in Web Test Runner, meaning we cannot bundle this dependency and must mark it as external and dynamic `import()` the package at runtime. This works fine in native ESM, but compiling with TypeScript outputs CommonJS code by default (and I don't believe our `@build_bazel_rules_nodejs` setup can easily change that), so any `import('@web/test-runner-core')` becomes `require('@web/test-runner-core')` which fails because that package is ESM-only. The `loadEsmModule` trick does work here either because Web Test Runner is applying Node module resolution at serve time, meaning it looks for `import('@web/test-runner-core')` and rewrites it to something like `import('/node_modules/@web/test-runner-core')`. In short, there is no easy syntax which circumvents the TypeScript compiler while also being statically analyzable to Web Test Runner.
For now this just runs ESBuild-er to build test code, Jest is not actually invoked yet.
This uses `glob` to find test files matching the given pattern. I went out of my way to limit `glob` functionality as much as possible in case we change the implementation later.
The deprecated 'defaultCollection' workspace option has been removed
BREAKING CHANGE:
The deprecated `defaultCollection` workspace option has been removed. Use `schematicCollections` instead.
Before
```json
"defaultCollection": "@angular/material"
```
After
```json
"schematicCollections": ["@angular/material"]
```
The deprecated 'defaultProject' workspace option has been removed
BREAKING CHANGE: The deprecated `defaultProject` workspace option has been removed. The project to use will be determined from the current working directory.
This change updates the analytics collector collector to use GA4 instead of UA. The motivation behind this change is that UA will stop collecting data in 2023.
BREAKING CHANGE:
`analyticsSharing` option in the global angular configuration has been
removed without replacement. This option was used to configure the Angular CLI to access to your own users' CLI usage data.
If this option is used, it can be removed using `ng config --global cli.analyticsSharing undefined`.
- Prevent additional properties being set in cli subproperties (i.e. cli.warnings.zzzz).
- Create cliGlobalOptions definition and reference in the global.cli schema.
- Use global.cli schema to validate changes made with --global flag.
- Add test coverage for validating global/local-only changes.
- Add test coverage for setting invalid properties and sub-properties.
The `schematicCollections` can be placed under the `cli` option in the global `.angular.json` configuration, at the root or at project level in `angular.json` .
```jsonc
{
"$schema": "./node_modules/@angular/cli/lib/config/schema.json",
"version": 1,
"cli": {
"schematicCollections": ["@schematics/angular", "@angular/material"]
}
// ...
}
```
**Rationale**
When this option is not configured and a user would like to run a schematic which is not part of `@schematics/angular`,
the collection name needs to be provided to `ng generate` command in the form of `[collection-name:schematic-name]`. This make the `ng generate` command too verbose for repeated usages.
This is where `schematicCollections` comes handle. When adding `@angular/material` to the list of `schematicCollections`, the generate command will try to locate the schematic in the specified collections.
```
ng generate navigation
```
is equivalent to:
```
ng generate @angular/material:navigation
```
**Conflicting schematic names**
When multiple collections have a schematic with the same name. Both `ng generate` and `ng new` will run the first schematic matched based on the ordering (as specified) of `schematicCollections`.
DEPRECATED:
The `defaultCollection` workspace option has been deprecated in favor of `schematicCollections`.
Before
```json
"defaultCollection": "@angular/material"
```
After
```json
"schematicCollections": ["@angular/material"]
```
Closes#12157
With this change we deprecate the angular.json `defaultProject` option.
DEPRECATED:
The `defaultProject` workspace option has been deprecated. The project to use will be determined from the current working directory.
Closes#20661
Persistent disk build cache is now enabled by default. A number of options have been added to allow fine tuning of the cache.
The options can be configuration in `cli.cache` section in the `angular.json` as shown below.
- `enabled`: Configure whether disk caching is enabled. Defaults to `true`
- `environment`: Configure in which environment disk cache is enabled. Valid values `ci`, `local` or `all`. Defaults to: `local`
- `path`: cache base path. Defaults to `.angular/cache`
DEPRECATED: `NG_BUILD_CACHE` environment variable option will be removed in the next major version. Configure `cli.cache` in the workspace configuration instead.
BREAKING CHANGE: `NG_PERSISTENT_BUILD_CACHE` environment variable option no longer have effect. Configure `cli.cache` in the workspace configuration instead.
```json
{
"$schema": "./node_modules/@angular/cli/lib/config/schema.json",
"version": 1,
"cli": {
"cache": {
"enabled": true,
"path": ".custom-cache-path",
"environment": "all"
}
}
...
}
```
All Angular builders are now located within one subdirectory of the `src` directory. This organization provides better discovery of the builders and will allow builder specific code to be stored in a single area.
With this change we automate the generation of `@angular/cli/lib/config/schema.json`. While on paper we could use quicktype for this. Quicktype doesn't handle `patternProperties` and `oneOf` that well.
How does this works?
Relative `$ref` will be resolved and inlined as part of the root schema definitions.
Example
```json
"@schematics/angular:enum": {
"$ref": "../../../../schematics/angular/enum/schema.json"
},
```
Will be parsed and transformed to
```json
"@schematics/angular:enum": {
"$ref": "#/definitions/SchematicsAngularEnumSchema"
},
"definitions: {
"SchematicsAngularEnumSchema": {
"title": "Angular Enum Options Schema",
"type": "object",
"description": "Generates a new, generic enum definition for the given or default project.",
"properties": {...}
}
}
```
The experimental rollup pass has significant issues with the new Ivy webpack plugin. It also, didn't produce as well as we hoped in real world scenarios infact in many cases this caused build to fail.
REAKING CHANGE:
The experimental rollup pass `--experimental-rollup-pass` option has been removed.
Closes#15836
With this change users can now their proxy server via the `HTTPS_PROXY` environment variable. The specified proxy will be used when making requests to inline fonts.
Closes#19401
It's confusing and redundant to use `When true` and `when false` in descriptions for a CLI arguments because specifying false/true is redundant in a command line argument flag and in most cases users will not do it.
Example:
`--foo=true` is the same as `--foo`
`--foo=false` is the same as `--no-foo`
This is another feature that we mentioned in the Eliminate Render Blocking Requests RFC (#18730)
Inlining of critical CSS is turned off by default. To opt-in this feature set `inlineCritical` to `true`.
Example:
```json
"configurations": {
"production": {
"fileReplacements": [
{
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.prod.ts"
}
],
"optimization": {
"styles": {
"minify": true,
"inlineCritical": true,
}
},
```
To learn more about critical CSS see;
https://web.dev/defer-non-critical-csshttps://web.dev/extract-critical-css/
In a future version of the Angular CLI `inlineCritical` will be enabled by default.
Closes: #17966Closes: #11395Closes: #19445
JSON files a can also be valid fileReplacement when using the `resolveJsonModule` TypeScript feature. This causes JSON files to be resolved as JS modules and hence be part of the TypeScript program.
Closes#19378
fileReplacement is meant to replace compilation source files (JavaScript or TypeScript) with other compilation source files in the build. With this change we add validation to fail the build when the files have unsupported extensions.
Closes#11451
By default subdirectories within a symlinked directory are not searched by a glob. The new `followSymlinks` option for the longhand form of the `assets` browser builder option now allows opting in to search such subdirectories.
