Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose.
This commit introduces a new `subPath` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `subPath` option is used, the `baseHref` is ignored. Instead, the `subPath` serves as both the base href and the name of the directory containing the localized version of the app.
Below is an example configuration showcasing the use of `subPath`:
```json
"i18n": {
"sourceLocale": {
"code": "en-US",
"subPath": ""
},
"locales": {
"fr-BE": {
"subPath": "fr",
"translation": "src/i18n/messages.fr-BE.xlf"
},
"de-BE": {
"subPath": "de",
"translation": "src/i18n/messages.de-BE.xlf"
}
}
}
```
The following tree structure demonstrates how the `subPath` organizes localized build output:
```
dist/
├── app/
│ └── browser/ # Default locale, accessible at `/`
│ ├── fr/ # Locale for `fr-BE`, accessible at `/fr`
│ └── de/ # Locale for `de-BE`, accessible at `/de`
```
DEPRECATED: The `baseHref` option under `i18n.locales` and `i18n.sourceLocale` in `angular.json` is deprecated in favor of `subPath`.
The `subPath` defines the URL segment for the locale, serving as both the HTML base HREF and the directory name for output. By default, if not specified, `subPath` will use the locale code.
Closes#16997 and closes#28967
When using the `ng add` command, the package version selection logic was not correctly selected based on the available versions in desc order. This could lead to selecting an unintended version of the package.
Closes: #28985
Updated TSDoc comments by replacing @note with @remarks across the codebase. This aligns with TSDoc's preferred conventions, where @remarks is used for supplementary explanations and additional context.
The optional application builder migration will now default to enabled and
recommended during the update process (`ng update`) for v19. The migration
is still optional and can be unselected if preferred when updating.
The Angular CLI will now enable the Node.js compile cache when available
for use. Node.js v22.8 and higher currently provide support for this feature.
The compile cache stores the v8 intermediate forms of JavaScript code for the Angular
CLI itself. This provides a speed up to initialization on subsequent uses the Angular CLI.
The Node.js cache is stored in a temporary directory in a globally accessible
location so that all Node.js instances of a compatible version can share the
cache. The code cache can be disabled if preferred via `NODE_DISABLE_COMPILE_CACHE=1`.
Based on initial profiling, this change provides an ~6% production build time
improvement for a newly generated project once the cache is available.
```
Benchmark 1: NODE_DISABLE_COMPILE_CACHE=1 node ./node_modules/.bin/ng build
Time (mean ± σ): 2.617 s ± 0.016 s [User: 3.795 s, System: 1.284 s]
Range (min … max): 2.597 s … 2.640 s 10 runs
Benchmark 2: node ./node_modules/.bin/ng build
Time (mean ± σ): 2.475 s ± 0.017 s [User: 3.555 s, System: 1.354 s]
Range (min … max): 2.454 s … 2.510 s 10 runs
Summary
node ./node_modules/.bin/ng build ran
1.06 ± 0.01 times faster than NODE_DISABLE_COMPILE_CACHE=1 node ./node_modules/.bin/ng build
```
I often struggle with spacing around block comments, so I've decided to add the `lines-around-comment` lint rule to help manage this.
For more details, see the https://eslint.style/rules/js/lines-around-comment
The Angular CLI will now enable the Node.js compile cache when available
for use. Node.js v22.8 and higher currently provide support for this feature.
The compile cache stores the v8 intermediate forms of JavaScript code for the Angular
CLI itself. This provides a speed up to initialization on subsequent uses the Angular CLI.
The Node.js cache is stored in a temporary directory in a globally accessible
location so that all Node.js instances of a compatible version can share the
cache. The code cache can be disabled if preferred via `NODE_DISABLE_COMPILE_CACHE=1`.
Based on initial profiling, this change provides an ~6% production build time
improvement for a newly generated project once the cache is available.
```
Benchmark 1: NODE_DISABLE_COMPILE_CACHE=1 node ./node_modules/.bin/ng build
Time (mean ± σ): 2.617 s ± 0.016 s [User: 3.795 s, System: 1.284 s]
Range (min … max): 2.597 s … 2.640 s 10 runs
Benchmark 2: node ./node_modules/.bin/ng build
Time (mean ± σ): 2.475 s ± 0.017 s [User: 3.555 s, System: 1.354 s]
Range (min … max): 2.454 s … 2.510 s 10 runs
Summary
node ./node_modules/.bin/ng build ran
1.06 ± 0.01 times faster than NODE_DISABLE_COMPILE_CACHE=1 node ./node_modules/.bin/ng build
```
Previously, when a select or checkbox prompt failed validation, it was bypassed, preventing users from correcting their input. This commit ensures that when validation fails, the prompts are re-displayed, allowing users to make the necessary corrections. This improves the user experience and helps avoid unintended selections.
Closes#28189
The schematics encapsulation process now uses a similar wrapping setup to
Node.js itself. This removes some custom code and also provides a more
comprehensive global object which should provide improved compatibility
for third-party packages used within schematics.
The `extract-i18n` command will now use a default project target and builder
name if the target entry is not explicitly defined. This allows the removal
of additional configuration from an `angular.json` file. If the target is
already present than it will take priority over any default builder behavior.
Infrastructure is also now present to allow other architect commands to
have similar functionality in the future.
As stated in https://github.com/angular/angular-cli/issues/11744,
`ng update` command removed the newline at the end of the package.json file.
This commit makes `ng update` to preserve newline, if it was present before running the command.
Fixes#11744
