With the migration to `rules_js`, package specific dependencies now only
need to be referenced with the source `package.json` for each specific
package. Most of the `@angular-devkit/core` specific dependencies have now been
moved. This is not exhaustive and further changes will continue to move
additional dependencies.
Several usages of `import { promises as fs } from 'node:fs'` have been
adjusted to import directly from `node:fs/promises`. This is consistent
with the rest of the source code usage.
With the migration to `rules_js`, package specific dependencies now only
need to be referenced with the source `package.json` for each specific
package. Most of the `@angular/cli` specific dependencies have now been
moved. This is not exhaustive and further changes will continue to move
additional dependencies.
Prior to this commit, analytics were not recorded for nested schematics. This caused certain data to be incomplete. For example, when running `ng new` and selecting "yes" for SSR in the prompt, this choice was not recorded because the prompt exists within the `application` schematic.
* build: disconnect `@npm` workspace from main project
This will speed up significantly as we don't need to fetch all
dependencies again just for the `@npm` repository that is at this point
only leveraged by the `ng_package` rule for some of its dependencies.
This commit allows us to drop the `yarn.lock` and Aspect lock files, and
allows us to independently migrate `ng_package` to `rules_js`.
It also allows us to drop the `_rjs` TS interop layer in follow-up commits.
* build: drop `_rjs` suffix from `ts_project` targets
We don't need the `ts_project` interop in principle
at this point. We only have one remaining instance left for the SSR
`ng_package` integration. This commit cleans up all usages.
* build: remove yarn
* build: avoid duplicated dependencies at top-level
`rules_js` seems to be sensitive if there are similar versions of the same
package installed, but with differently matched peer dependencies. This
is fine because we can (and should long-term) move those dependencies to
their package-local `package.json` files. This commit unblocks the
migration and highlights how we can move deps to the individual packages
in the future.
* build: update checkout github action
This will allow us to use pnpm.
* build: update node to avoid strict-engines error caused by `npm`
Avoids:
```
Lockfile is up to date, resolution step is skipped
ERR_PNPM_UNSUPPORTED_ENGINE Unsupported environment (bad pnpm and/or Node.js version)
Your Node version is incompatible with "npm@11.2.0".
Expected version: ^20.17.0 || >=22.9.0
Got: v20.11.1
```
Note that we won't update the WORKSPACE test version as that would mean
we need to update the Node engines for shipped packages; and we can't do
this right now without introducing a breaking change.
* build: fix missing dependency for spec bundling
The beasties JS sources weren't available for bundling in the
`bazel-bin`, and this surfaced in RBE. This commit fixes this.
Node.js v18 will reach its End-of-Life on 2025-04-30 and as a result will
not be supported with the upcoming Angular v20.
Node.js Release Schedule: https://github.com/nodejs/release#release-schedule
BREAKING CHANGE: Node.js v18 is no longer supported with Angular.
Before updating a project to Angular v20, the Node.js version must be
at least 20.11.1. For the full list of supported Node.js versions,
see https://angular.dev/reference/versions.
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.
