The library schematic currently relies on Karma, which requires `@angular-devkit/build-angular` to be installed. To address this, we now use the `ng-packagr` builder provided in this package.
Closes#29494
This commit renames `provideServerRoutesConfig` to `provideServerRouting` and updates the second parameter to use the `ServerRoutes` features.
This change improves alignment with the framework's API conventions and the way features are integrated.
### Example Usage:
Before:
```typescript
provideServerRoutesConfig(serverRoutes, { appShellRoute: 'shell' })
```
After:
```typescript
provideServerRouting(serverRoutes, withAppShell(AppShellComponent))
```
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.
Refined and clarified the descriptions for various schematics options to improve their readability and accuracy. These changes aim to make the documentation more user-friendly and accessible for developers.
Closes#25571
* 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.
The `use-application-builder` update migration will now attempt to migrate
the `ng-packagr` builder to use the `@angular/build` package if no other
`@angular-devkit/build-angular` usage is present.
The newly introduced `ng-packagr` builder within the `@angular/build` package
is now used when generating a new library with `ng generate library`. This
builder provides the same functionality as the `ng-packagr` builder found
within the `@angular-devkit/build-angular` package but removes the need for
projects to install `@angular-devkit/build-angular` if using the `application`
builder from `@angular/build`.
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
Apparently `inquirer` requires `async_hooks` which isn't supported in webcontainers, therefore prompting the user fails. Instead we always fall back to the default option.
See: https://github.com/SBoudrias/Inquirer.js/issues/1426
The new routing APIs don't support `browser` builder, but calling `ng add @angular/ssr` with a `browser` builder would still prompt the user to add them. If the user said "Yes", it would actually ignore that answer and not enable the new APIs.
With this change, `ng add @angular/ssr` when using `browser` builder does not show the prompt and assumes the answer is "No". It also throws an error if the user runs `ng add @angular/ssr --server-routing`.
I'm not aware of a built-in prompting mechanism in schematics beyond `x-prompt`, which can't be used here, so instead I just called Inquirer directly. Unfortunately testing the prompt is a little awkward, as Inquirier does not provide useful APIs in this space. I evaluated `@inquirer/testing`, but ultimately decided that was more intended for testing custom Inquirer prompts, not mocking usage of standard prompts. Schematics APIs do not provide a useful way to inject additional data like a mock, so instead I had to do this through a `setPrompterForTestOnly` function. I'm not a huge fan of it, but I don't see a more straightforward way of solving the problem.
This commit removes the `RenderMode.AppShell` option. Instead, a new configuration parameter, `{ appShellRoute: 'shell' }`, is introduced to the `provideServerRoutesConfig` method.
```ts
provideServerRoutesConfig(serverRoutes, { appShellRoute: 'shell' })
```
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 generated spec was using the same import when it should be adapted if `exportDefault` is used:
```ts
import { UserComponent } from './user.component.ts`
```
It now produces:
```ts
import UserComponent from './user.component.ts`
```
This commit implements the capability for the App Engine to serve prerendered pages directly. Previously, we relied on frameworks like Express for this functionality, which resulted in inconsistent redirects for directories where in some cases a trailing slash was added to the route.
**Note:** This change applies only when using the new SSR APIs. When using the `CommonEngine`, a 3rd party static serve middleware is still required.
This commit updates several schematics to make the new `@angular/ssr` feature opt-in. Users can opt in by using the `--server-routing` option or by responding with `yes` to the prompt.
Some cloud providers, such as Cloudflare, expect the default export to follow a specific structure (e.g., an object with a `fetch` property). To prevent the need for creating a separate `server.ts` file for production builds, the request handler is now exported as `reqHandler` instead of a default export.
This commit revises the app-shell and ssr schematics to incorporate the new Server Rendering API, along with the integration of server-side routes.
BREAKING CHANGE: The app-shell schematic is no longer compatible with Webpack-based builders.
Event Replay is now stable (see https://github.com/angular/angular/pull/57895). This commit adds `withEventReplay()` to the `provideClientHydration()` call in newly created Angular applications with SSR.
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
Newly generated projects will now no longer have an explicit `lib` option defined
within the TypeScript configuration for the workspace (`tsconfig.json`). This
option will default to the `target` option value plus `DOM`. This combination is
the same as the explicit value set in a new project. Removing the explicit option
value will result in equivalent behavior without the need to duplicate the ES
version in two places.
