* 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.
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
The `@angular/build` package is now used directly within all newly created
projects and replaces the previous usage of the `@angular-devkit/build-angular`
package. This has the advantage of removing the need to install all of the
Webpack related transitive dependencies contained within `@angular-devkit/build-angular`
that are used to support the `browser` builder. This results in a significant
reduction in both total dependency count and disk install size for new projects.
New projects that would prefer to use the Webpack-based `browser` builder can still
install the `@angular-devkit/build-angular` package within the workspace.
The `@angular/build@19.2.0-next.2` package currently has a total unpacked size of ~115 MB.
The `@angular-devkit/build-angular@19.2.0-next.2` package currently has a total unpacked size of ~291 MB.
Previously, component styles were included in the 'any' and 'all' budgets, which could lead to incorrect budget violations. This update ensures that component styles are excluded from these budget calculations.
Closes#29609
When the service worker option is enabled, each code update will cause
the `ngsw.json` configuration file to change due to the different hashes
of the updated output. This is problematic for component HMR usage with
the development server since the full reload fallback logic would be triggered
due to the changed `ngsw.json` file. To avoid this problem, the `ngsw.json`
configuration file is now special cased within the fallback logic.
As part of go/ng:windows-dev-future, we are changing how our
infrastructure supports Windows build & testing. Clearly:
- we will still support contributors on Windows, and we believe we will
be improving and streamlining the experience here
- we will continue testing the Angular CLI for our Windows users. We are
aware of the many Windows users using the `ng` CLI.
What is changing? We are no longer actively working towards a Bazel infrastructure
that supports native Windows building and testing. There are currently
two ways to contribute to Angular on Windows. That is via WSL, or via
e.g. native Windows cmd.exe, with Git Bash on top. We acknowledge that
the latter worked sometimes, but we also realize it very often breaks as
nobody on our team uses, verifies it, and it introduces extra complexity
because Bazel on Windows is quite disconnected from Linux/Mac (e.g. no
sandboxing). Going forward, to improve our team's effectiveness, and
improve our stability guarantees for Windows (and Windows contributors),
we are actively discouraging the use of Git Bash for contributing to
Angular; but instead ask for WSL to be used. I can speak as one of the
few long-term team members that have worked on Windows (without WSL) most
of my time, that WSL is great and the contributing experience is much
smoother and also easier to "guide". It's a positive change because we
won't be suggesting "two ways to contribute on Windows", where in
reality one is very brittle and can break at any time!
---
For testing of the Angular CLI: We will continue to maintain the
capability to cross-compile via Bazel with Windows as the target
platform. This allows us to build the e2e tests for Windows, and run
them natively outside WSL to ensure native Windows `ng` CLI testing!
This is what this change mostly does.
Notably, two things are missing here and will be followed up:
- caching of the e2e tests on Windows is not properly functioning yet.
- caching of the WSL node modules + nvm is not working properly yet.
Other than that, we are seeing very similar timing and results of the
Windows tests, so this change unblocks our `rules_js` migration.
When on Windows, the coverage exclusion paths need to be made
absolute via the Node.js path builtin to ensure matching
with the files during the build process.
Usage of the `fast-glob` package has been replaced with the `tinyglobby`
package throughout `@angular/build`. The change reduces the number of
transitive dependencies related to these packages from 17 to 2 while
also maintaining equivalent functionality. Additionally, the `tinyglobby`
package is used by other dependencies such as `vite` and `copy-webpack-plugin`
which has the potential to further reduce overall transitive dependencies
for a project.
Previously, JIT component resource URLs in sourcemaps included a `file:` prefix (e.g., `file:src/app/app.component.html`). This change removes the `file:` prefix to ensure cleaner source mappings.
There can be cases where the `less` stylesheet preprocessor will return
an undefined value for a sourcemap even though sourcemaps have been enabled.
A check is now performed to handle these cases to prevent potential crashes
when processing `less` styles.
When using the development server, the `statsJson` option will now
unconditionally be disabled. The output JSON file is not accessible
with the server and the analysis/generation of the JSON file may
increase the rebuild time. Additionally, the JSON file changes during
a rebuild may unexpectedly cause component HMR fallback to a full
reload due to non-component file changes in the build output.
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
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
