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/build` specific dependencies have now been
moved. This is not exhaustive and further changes will continue to move
additional dependencies.
- Migrate imports of `provideServerRendering` from `@angular/platform-server` to `@angular/ssr`.
- Update `provideServerRendering` to use `withRoutes` and remove `provideServerRouting` from `@angular/ssr`.
This commit introduces `provideServerRendering` as the primary function for configuring server-side rendering, replacing `provideServerRouting`. `provideServerRendering` now includes the functionality of `provideServerRouting` through the use of the `withRoutes` feature.
This change consolidates server-side rendering configuration into a single, more flexible function, aligning with the evolution of Angular SSR.
**Before:**
```ts
import { provideServerRouting } from '@angular/ssr';
import { serverRoutes } from './app.routes';
provideServerRouting(serverRoutes);
```
**After:**
```ts
import { provideServerRendering, withRoutes } from '@angular/ssr';
import { serverRoutes } from './app.routes';
provideServerRendering(withRoutes(serverRoutes));
```
Currently the `while` loop may either be causing the process to be
really stuck/hanging, or it somehow causes Node to exit.
This change makes the logic more robust and less CPU consuming.
To align with the updated style guide, Angular v20 will generate services
without a `.service` file extension type for all service related
files by default. Projects will automatically use this naming convention.
Projects can however opt-out by setting the `type` option to `Service`
for the service schematic. This can be done as a default in the `angular.json`
or directly on the commandline via `--type=Service` when executing `ng generate`.
As an example, `example.service.ts` will now be named `example.ts`. Additionally,
the TypeScript class name will be `Example` instead of the previous `ExampleService`.
The `library` schematic will now longer generate an empty Angular service
with the name of the library. Using only the name would generate a file
name conflict with the component now that the type suffix is no longer
used by default. Additionally, services tend to be specific to a particular
behavior and/or functionality and are named as such. A generically named
empty service will typically be deleted or renamed.
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.
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.
