To align with the updated style guide, Angular v20 will generate components
without a `.component` file extension type for all component related
files by default. Projects will automatically use this naming convention.
Projects can however opt-out by setting the `type` option to `Component`
for the component schematic. This can be done as a default in the `angular.json`
or directly on the commandline via `--type=Component` when executing `ng generate`.
As an example, `app.component.css` will now be named `app.css`. Additionally,
the TypeScript class name will be `App` instead of the previous `AppComponent`.
The Angular module discovery logic previously did not check for the presence
of a potential `@NgModule` decorator. This can cause false positive results
for files with a module-like naming pattern.
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/build-angular` and `@angular-devkit/build-webpack`
specific dependencies have now been moved. This is not exhaustive and further
changes will continue to move additional dependencies.
An `ngHmrMode` boolean value will now be defined within application bundles.
The value is based on the development server's `hmr` option with `true`
when HMR is enabled and `false` when disabled. For all application builds,
the value will be `false`. `ngHmrMode` is similar in behavior to `ngServeMode`
or `ngDevMode`. It will not be present in the output code unless referenced
and in those cases only the final boolean value will be present if not optimized
out of the final code.
The value is not considered part of the public API and may change in the future.
The karma configuration will now automatically set the `basePath` option
to the temporary output path when using the application build system's
karma testing. This ensures that only the relative path of the test files
is represented in the stack traces of test failures.
Server-side rendering (SSR) will always enable server routing when using the application builder.
BREAKING CHANGE: `--server-routing` option has been removed from several schematics. Server routing will be used when using the application builder.
This commit promotes the `AngularNodeAppEngine`, `AngularAppEngine`, and `provideServerRouting` APIs from dev preview to stable. These APIs enhance server-side rendering (SSR) capabilities in Angular applications, improving routing and server integration for better performance and reliability.
For our native Windows tests (verifying `ng` CLI outside WSL), we
currently build the test binaries inside WSL, leveraging bazel remote
execution.
The scripts involved in moving the built binaries to outside WSL rarely
flake due to a WSL interop bug when we invoke Windows commands from inside
WSL (which is an untypical thing to do; but a needed trick given some WSL limitation).
This commit tries to stabilize/avoid this flake by retrying if we
recognize this.
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.
To align with the updated style guide, Angular v20 will generate
component templates with a `.ng.html` file extension instead of
the previous `.html` by default. Projects will automatically
use this new template extension. Projects can however opt-out of
component generation using `.ng.html` by setting the `ngHtml`
option to false for the component schematic. This can be done as
a default in the `angular.json` or directly on the commandline
via `--no-ng-html` when executing `ng generate`.
The configuration now ensures that when a package is listed for exclusion, all paths within that package including sub-paths like `@foo/bar/baz` are marked as external and not prebundled by the development server.
For example, specifying `@foo/bar` in the exclude list will prevent the development server from bundling any files from the `@foo/bar` package, including its sub-paths such as `@foo/bar/baz`.
This aligns with esbuild external option behaviour https://esbuild.github.io/api/#externalCloses#29170
Newly generated projects will now use the `preserve` value for the `module` option
within the TypeScript configuration for the workspace (`tsconfig.json`). This value
was added in TypeScript 5.4 and is intended to model the behavior of modern bundlers
such as used in the default `application` builder.
This option value also has the advantage of automatically enabling `esModuleInterop`
and setting `moduleResolution` to `bundler` which are the currently generated values
for new projects. This allows explicit use of these options to be removed from the generated
file. The `resolveJsonModule` option is also enabled with `preserve` which removes
the need for developers to manually add it if JSON files are imported. JSON file imports
are fully support including unused property treeshaking with named imports in the
`application` builder.
Additional details on the option can be found here:
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-4.html#support-for-require-calls-in---moduleresolution-bundler-and---module-preserve
