Comparing changes

…#3738) The SSR deploy builder shelled out with values read straight from angular.json: the package manager and each server externalDependencies entry reached `execSync` as a command string, as did the functions output path. A malicious or cloned workspace could run arbitrary commands the moment a developer ran `ng deploy`. Both calls now go through a single runner built on cross-spawn, which passes arguments as argv entries and launches the Windows .cmd shims that child_process.execFile cannot, so the deploy keeps working cross-platform without a shell. The package manager is checked against a supported set and dependency names are rejected unless they are plain specifiers. Tests cover the validators and assert the call sites route through the shell-free runner, so reverting to a shell or dropping a validator fails the suite. (cherry picked from commit 0e8ed0c)

…ring (#3726) spawnAsync built each gcloud command as one string and split it on whitespace before calling spawn(), so any deploy option containing a space was chopped into extra argv entries and a value from angular.json could add flags of its own. It now takes command and args separately and the three call sites pass arrays, removing the join and split entirely. The close handler also rejected only on exit code 1, so a gcloud failure with any other code, or a process killed by a signal, resolved as success and a failed deploy reported as done. It now rejects on any non-zero or null code. The Cloud Run argument construction moved into two exported functions so tests can assert the argv shape without mocking spawn, and functionName and region gained schema patterns, since both also reach the generated Cloud Functions source. (cherry picked from commit 778625a)

) Running ng deploy from Windows with the Cloud Run SSR option wrote the generated run/package.json entry paths with backslashes, which the Linux-based Cloud Run runtime cannot resolve. The manifest path is now built with forward slashes explicitly, since the target runtime is Linux regardless of the deploying machine. Fixes #3098 Co-authored-by: Armando Navarro <adnavarro@google.com> (cherry picked from commit 73acea7)

…es (#3739) The SSR deploy builders interpolate several angular.json values into generated artifacts that are later executed: a server build target's outputPath into the Cloud Function index.js and the Cloud Run package.json start script, functionName into the exports assignment, region into the .region() call, and functionsNodeVersion into the Cloud Run Dockerfile FROM line. region is escaped structurally with JSON.stringify in the template, and the start script now quotes its path, so a shell no longer splits or expands it. On top of that, outputPath, functionName and functionsNodeVersion are screened before code generation (assertSafeOutputPath, assertSafeFunctionName, assertSafeNodeVersion). assertSafeOutputPath rejects only what is still live once the start script is quoted: quotes, a backslash and line terminators, which break out of the require() string literal, `$` and a backtick, which are still command substitution inside double quotes, and a leading dash, which node reads as a flag. functionName is only screened on the Functions path, where it becomes a JavaScript identifier. functionsNodeVersion is screened against Docker's tag grammar, since the value is a node image tag, with latest excluded because its slim variant is published as node:slim. The functionName and region schema patterns are not repeated here. Stricter versions of both already landed on main in #3726. The functionsNodeVersion schema pattern stays here and matches the runtime check exactly. The TODO above the gcloud calls is restored in narrowed form, covering the values that are still unvalidated: firebaseProject, vpcConnector, and the outputPath deploy option. (cherry picked from commit fb6796b)

…3769) firebase-tools 15.26 runs non-interactively when it detects an AI agent or when stdin is not a terminal, and in that mode login() returns undefined instead of the signed-in account. `ng add` and `ng deploy` crashed reading `.email` from it. getActiveAccount passes `interactive: true`, which returns the account without a prompt once one is signed in. The `firebase login` and `firebase login:add` commands setup starts get `--interactive` for the same reason. Setup no longer passes its options to login(), since they carry the Angular project name, which firebase-tools rejects as a project id for names like `myApp`. The Quickstart stops telling readers to install firebase-tools 14, and says what a stopped run leaves behind. Fixes #3768 The Quickstart changes are left out, since docs are not backported. (cherry picked from commit 38dfc3f)

…3784) Every canary publish moved the `canary` dist-tag, whatever commit it was built from. Two merges close together could publish out of order, and a re-run of an older run could publish its build last. The publish job now clones the repository's commit history and publishes a canary only when its commit comes after the commit of the canary on npm, or is the same commit under a new version. A build of an earlier commit is skipped with a warning. Commits are compared rather than versions, because a version can be higher for an older commit. Canary publishes also run one at a time, queued, so each check reads what the previous publish left on npm. Release publishes are unchanged. A scheduled run on an unchanged main now skips with a notice instead of failing on the duplicate version. Fixes #3783 (cherry picked from commit eee3486)

) npm 10, and npm 11 before 11.20, resolve a missing optional peer anyway while installing. For an app whose package.json uses caret ranges and whose Angular is one patch behind the newest, npm picks the newest @angular/platform-server, which requires that exact newest @angular/core, and the install stops with ERESOLVE. Every current Node line bundles one of those npm versions. Nothing in the published package imports @angular/platform-server, so the peer is removed. Apps that render on the server still install it themselves, as they already do. (cherry picked from commit bbce8f0)

… after it (#3794) * fix(ci): choose a release's dist-tag when it publishes, and move next after it A stable tag published to latest unconditionally, so a 20.x release tagged after 21.0.0 would move latest back to 20.x. A stable release now goes to latest only when it ranks above npm's latest and every other stable git tag, since a higher release can still be in npm's publish-time malware scan. Otherwise it goes to v<major>-lts, and the job fails if it does not rank above that tag or another release of its major. Every publish now waits until npm lists it, in one npm-publish queue, so the next publish reads the real dist-tags. That stops a queued canary from reading a stale canary tag. After a release reaches latest, next moves up to it, and a failure there prints the npm dist-tag command that finishes it. A re-run of a published release skips npm publish and goes on to the wait and the next move. The steps live in tools/publish-job.js and tools/release-tag.js so specs cover them, and build.sh no longer picks a tag. * refactor(ci): move the canary check into tools/publish-job.js The check that skips a canary of an earlier commit keeps the same decisions and messages, and its specs now cover each branch. It runs only for pushes and scheduled runs, and a failed read of npm's dist-tags now says why. (cherry picked from commit 31fb2ae)

The publish job's specs (tools/publish-job.jasmine.ts and tools/release-tag.jasmine.ts) live under tools/. On main, #3780 added this include, and #3780 itself stays off 20.1.x, so without it build:jasmine never compiles those 39 specs and test:node skips them without failing.

fromTask declared no return type, so the published typings import whatever path the typings bundler picks for the inferred firebase type. In 20.x that is 'firebase/compat', which firebase's exports map does not list. Apps using moduleResolution "bundler", the setting the @angular/build migration moves apps to, fail with TS2307 in @angular/fire/compat/storage. 21.0.0-rc.1 happens to emit 'firebase/compat/app' and compiles, but ng-packagr 22.2's new typings bundler cannot parse the inferred type and fails the library build. Declaring Observable<UploadTaskSnapshot> removes the inferred import. The type is unchanged: UploadTaskSnapshot is the compat alias for firebase.storage.UploadTaskSnapshot. Also drop a comment explaining a firebase import that #3421 removed in 2023 as unused. The import only existed to steer these typings. Fixes #3677 (cherry picked from commit 4c5ba7e)

…3770) AngularFire wrapped beforeAuthStateChanged so that registering the hook added a pending task, cleared only when the callback first runs. Firebase runs that callback only on a sign-in or sign-out, so for a visitor who does neither the app never became stable. Registered on the server, it failed ng build during route extraction and left server-rendered requests without a response. This restores the blockUntilFirst: false override from #3590, which #3613 dropped without comment while adding log-level overrides next to it. The callback still runs inside Angular's zone and injection context, and its returned promise still reaches Firebase, so a rejection still cancels the sign-in. A call outside an injection context now logs its per-call warning only at the verbose level, as onMessage does. Fixes #3748 docs(auth): scope the beforeAuthStateChanged note to rc.1 and earlier Merging this change closes #3748, so the section's present-tense note would point at a closed issue. Also removed the false claim that the @angular/fire/auth import makes ng build hang: the guide registers the hook only in the browser, so its own build succeeds. The docs/auth.md change is left out, since it edits a section of the guide that 20.1.x does not have. (cherry picked from commit f182972)

Navigation Menu

Repository navigation

Comparing changes

Open a pull request

Commits on Oct 10, 2026

This comparison is taking too long to generate.

Uh oh!