When executing unit tests with `karma`, the stack traces within errors
will now use any sourcemaps that were generated during the build process
to provide source-based locations for the errors. Script sourcemaps must
be enabled for this functionality.
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
This update improves the handling of inlined critical CSS to align with `autoCsp`, ensuring compliance with Content Security Policy (CSP) directives. Previously, inlined styles could trigger CSP violations in certain configurations. With this fix, critical CSS is inlined in a way that maintains security while supporting `autoCsp`.
Closes#29603
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 HMR component update candidate analysis has been improved to now perform
more fine-grained checks for cases where more than one component is present
in a single TypeScript file. Previously it was possible for all components
present in a TypeScript file to be considered update candidates when only
one of the components had relevant changes to its template and/or styles.
Vite's `allowedHosts` option does not enable CORS; instead, it allows the dev server to respond to requests with a matching hostname (e.g., http://example.com/main.js). It only verifies that the request’s hostname is on the allowed list. However, this does not consider the `origin` in the case of a CORS request.
This commit updates Vite's configuration to enable CORS.
Closes#29549
When disk caching is enabled, translated i18n bundles are stored on disk, improving performance and speeding up both incremental and non-incremental builds.
In addition to the WebSocket code, the Vite client module contains helper
functions which may be injected into modules at request time. These helpers
are required for certain behavior to function. Previously, when `--no-live-reload`
was used, these helpers may not have been available which led to runtime
errors. These runtime errors will no longer occur. However, the browser console
will now log that the Vite client cannot connect to the development server
WebSocket. This is expected in this case since live reload functionality
was disabled and the server side is intentionally not available.
JS engines convert `\r\n` to `\n` in template literals, potentially leading to incorrect byte length calculations. This fix ensures the correct content length is determined.
Closes#29567
If an initial build of an application results in an error during watch mode
(including `ng serve`), the following non-error rebuild will now always be
a full build result. This ensures that all new files are available for later
incremental build result updates.
Vite 6.0 change the option location of the `preTransformRequests`
to the `dev` section of the Vite configuration. While the previous `server`
section option of the same name is still present, it currently does not
change behavior when configured.
If HMR is enabled, a component update has the potential to be unsupported
at runtime or may cause an exception. While build time analysis attempts
to verify that an update is possible, there could be cases that are as of
yet unknown. For those cases, the runtime can now signal this information
back to the development server which will clear the errant component update
and trigger a full page reload. This action will be logged to the development
server console along with an optional message from the client.
Ensures that the SSR router gives precedence to the first matching route, addressing the issue where later conflicting routes.
This change prevents the incorrect prioritization of routes and ensures the intended route is matched first, aligning routing behavior.
Closes: #29539
This commit adds support for custom route matchers in Angular SSR, allowing fine-grained control over the `renderMode` (Server, Client) for individual routes, including those defined with matchers.
Routes with custom matchers are **not** supported during prerendering and must explicitly define a `renderMode` of either server or client.
The following configuration demonstrates how to use glob patterns (including recursive `**`) to define server-side rendering (SSR) or client-side rendering (CSR) for specific parts of the 'product' route and its child routes.
```typescript
// app.routes.ts
import { Routes } from '@angular/router';
export const routes: Routes = [
{
path: '',
component: DummyComponent,
},
{
path: 'product',
component: DummyComponent,
children: [
{
path: '',
component: DummyComponent,
},
{
path: 'list',
component: DummyComponent,
},
{
matcher: () => null, // Example custom matcher (always returns null)
component: DummyComponent,
},
],
},
];
```
```typescript
// app.routes.server.ts
import { RenderMode, ServerRoute } from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{ path: '**', renderMode: RenderMode.Client },
{ path: 'product', renderMode: RenderMode.Prerender },
{ path: 'product/list', renderMode: RenderMode.Prerender },
{ path: 'product/**/overview/details', renderMode: RenderMode.Server },
];
```
Closes#29284
Switches the beasties bundling to `rules_js`, using rollup directly from
the node modules installation.
Notably we are facing a small issue that doesn't cause any issues right
now, because rollup tries to dereference symlinks by default given
a bug: https://github.com/aspect-build/rules_js/issues/1827.
This means we can't rely on the jailed resolution, but in practice it
shouldn't cause an issue at this point.
This file is currently no longer necessary after migrating all consumers
to their `rules_js` variants, so we can delete the file.
In follow-ups we will consider renaming `defaults2.bzl` back to this
file, or have a better name altogether.
Previously, when an unknown `main.js` file was requested, the system would
automatically fall back to serving the default `main.js`. This behavior
could cause unexpected issues, such as incorrect resource loading or
misleading errors.
This fix ensures that only valid `main.js` files are served, preventing
unintended fallbacks and improving request handling.
Closes#29524
When redirecting to the preferred locale, the previous implementation used the full URL for the 302 redirect to i18n subpaths based on the user's preferred locale. This update ensures that the redirect now uses the locale-specific pathname instead of the full URL.
Closes#29514
Migrates the `@angular-devkit/build-angular` tests to `rules_js`. This
was a rather larger undertaking as the tests were very reliant on e.g.
the directory structure or specific node module layout; so some changes
were needed.
- the Sass files include a much larger file header now. That is because
the npm Sass files have much larger paths, given being inside a
symlinked pnpm store directory. E.g.
```
/*!**********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************!*\
!*** css ../../../../../node_modules/.aspect_rules_js/css-loader@7.1.2_webpack_5.97.1/node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[4].rules[0].oneOf[0].use[1]!../../../../../node_modules/.aspect_rules_js/postcss-loader@8.1.1_1462687623/node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[4].rules[0].oneOf[0].use[2]!./src/test-style-a.css?ngGlobalStyle ***!
\**********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************/
.test-a {color: red}
```
- Similarly to above, hashed chunk files can change given different
paths of e.g. Webpack, or external sources.
- Tests for verifying the lazy module chunks may enable
`preserveSymlinks` just to make the chunk names shorter and easier to
verify, avoiding truncatd super long paths to the e.g. pnpm stores
again.
- the ngsw-worker.js file cannot be copied using `copyFile` as that
results in permissions being copied as well. In Bazel, now that
the npm files are properly captured, are readonly, so subsequent
builds (e.g. the watch tests) will fail to copy/override the file
again! Reading and writing the file consistently seems appropriate.
- Tests relying on puppeteer and webdriver-manager worked in the past,
by accident, because postinstall scripts (from e.g. puppeteer) were
able to modify content of other packages (e.g. the puppeteer-core
cache of browsers then). This does not work with `rules_js` anymore,
so we need to keep the cache local to the puppeteer postinstall
script. This requires a little trickery right now to ensure resolution
of the browsers at runtime works..
- server tests did miss the `node` types to be explicitly listed (as
they would be in a fresh project), and this caused failures. Likely
because we no longer patch resolution.
- avoid npm-module style imports from tests within the same package.
This is not allowed with `rules_js` and also is inconsistent.
