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
With standard decorator support now available for use, the memoize decorator
has been updated to be a standard decorator instead of a TypeScript experimental
decorator. This change also removes the only usage of decorators within the
Angular CLI code itself. This change does not affect application code.
To remove the tsetse rule exclusions, several usages of `JSON.parse` that
did not have type casting where adjusted to add types. This removed the
need for the manual configuration within the tsconfig.
The `isTTY` and `supportColor` helpers can now accept a stream to check
instead of assuming stdout. This is useful if stderr needs to be checked,
for instance. Also, color checking now uses Node.js `hasColors` where
possible which has been available since Node.js v10.
The ora package has been removed now that the progress indicator for the
update command is now based on the `listr2` package that is also used
by the `ng add` command.
The `listr2` dependency that was recently introduced to improve the console
UI for the `ng add` command is now used for the package installation step
of the `ng update` command process.
The newly introduced `listr2` dependency used for the updated `ng add`
console UI provides color support. This removes the need to retain a
direct dependency on a color package within the `@angular/cli`.
The step-based console UI of the add command has been refactored to use the `listr2` library.
Previously, an `ora` spinner was manually used and needed to handle a
variety of error conditions and could not handle the potential for concurrent
tasks as well as streaming subcommands cleanly while the spinner was in use.
Behavior of the add command has not been changed during this refactor. Further
improvements are possible including the integration of the schematic execution
within the step-based UI.
Before this commit, running `ng update @angular/cli` would fail when using the PNPM package manager. This update resolves the issue by implementing fallbacks in the migration package resolution logic, similar to the approach used in `NodeWorkflow`.
