An `application` only variant of the `karma` builder found within the
`@angular-devkit/build-angular` package is now available within the
`@angular/build` package as `@angular/build:karma`. This builder will
only use the `application` builder found within `@angular/build` and
does not provide the `builderMode` option as `application` would be the
only valid value. Testing behavior is effectively equivalent to using the
`@angular-devkit/build-angular:karma` builder with the `builderMode`
option set to `application`. However, several options have been adjusted:
* `builderMode` was removed
* `fileReplacements` legacy structure (`src`/`replaceWith`) removed
* `polyfills` only accepts an array of strings
* `loader` has been added
* `define` has been added
* `externalDependencies` has been added
Previously, the package group name defaulted to the first item in the list. This update prioritizes an installed package as the fallback instead.
Closes#29627
Previously, the logic incorrectly extracted the drive letter as the collection name when the schematic collection was specified as relative on Windows. This fix ensures that relative paths are parsed and resolved correctly, preventing the drive letter from being mistakenly treated as the collection name.
Closes#29559
The link to the README was relative, which caused it to break when viewed on the npm repository. The link has been updated to an absolute URL to ensure it works properly.
In certain scenarios, users build applications with the same `baseHref` when using i18n, primarily for deploying localized applications across multiple domains. To address this, we are removing the deprecation of `i18n.baseHref` and will revisit potential options as part of https://github.com/angular/angular-cli/issues/29111
Instead of deprecating `i18n.baseHref`, we now issue a warning when it is used with SSR, as this may lead to undefined behavior.
Closes#29396
Integrates `@angular/cli` into the pnpm workspace and wires up the
native `rules_js` rules.
One nice benefits that highlight here:
- `resolve` runtime dependency is only installed in the CLI folder, and
we can pull it from there. --> Locally managed deps! :yay:
This is necessary as `rules_js` requires this "common name" when dealing
with Yarn workspaces, linking first party dependencies automatically.
In the future, we may be able to send a PR to `rules_js` to support a
custom name somehow.
Similart to `pkg_npm` from `rules_nodejs`, we should have a way to make
use of the stamp constants/placeholders throughout individual package
files. This is not possible at all with `rules_js`'s `npm_package` rule,
nor does it support stamp substitutions out of the box at all.
We have our own `expand_template` machinery to substitute `package.json`
files of npm archives, but we need to expand this to support arbitrary
files inside a package. This will be opt-in for explicitly listed files;
which is a good compromise for simplicity of supporting this.
This commit adds the necessary functionality and demonstrates the
feature by fixing `@angular/build`.
* Removes `interop_deps` from the `ts_project` interop macro.
* Keeps `_rjs` suffix for now as we still need the interop targets for
e.g. `jasmine_node_test` and the `rules_nodejs` linker.
In follow-ups we can remove the suffix, and interop layer.
To support migration to the `@angular/build` package which contains the
`application` builder that is used by all new projects, the `ng-packagr`
builder used to build Angular libraries is also now available within this
package. This removes the need for projects that are using the application
builder but also would like to build a library from having to install the
Webpack related `@angular-devkit/build-angular` package. This can result
in a significant reduction in overall Node.js packages installed within the
project.
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
```
