Comparing changes

…config (#3707) The Firebase CLI's apps.sdkconfig response includes management-API fields (projectNumber, version, locationId) alongside the web app config. The schematic only deleted locationId and inlined the rest into initializeApp(), so the generated app failed to compile with TS2769: 'projectNumber' does not exist in type 'FirebaseOptions'. Keep only the keys FirebaseOptions accepts, so future additions to the CLI response cannot break the generated config again.

…functions (#3730) The SSR Cloud Function generated by `ng deploy` crashed at cold start: Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/logger/compat' is not defined by "exports" in node_modules/firebase-functions/package.json Both generated templates required `firebase-functions/lib/logger/compat`. firebase-functions declares an exports map, and the internal `lib/` path is not in it. The exported subpath is `firebase-functions/logger/compat`, which maps to the same file. Verified by generating the function source and loading it against a real firebase-functions install: the shipped path throws, the exported path loads and emits structured Cloud Logging JSON, which is what the compat logger is there to do. This affects the deployed function rather than the build, so it fails at runtime in Cloud Functions rather than during `ng deploy`, and it is present in both the 20.x and 21.x lines. (cherry picked from commit a99f09b)

Every platform-browser-dynamic 20.x/21.x patch release requires the exact @angular/core and @angular/common version matching its own patch. Declaring pbd as a required peer therefore makes npm pull in a pbd version whose required core/common usually differs from the app's installed core/common, failing `ng add @angular/fire` with ERESOLVE on Angular >= 20.1 apps. Nothing in the published package imports platform-browser-dynamic; the only usage in the repo is the Karma test bootstrap (src/test.ts), which is supplied by the root package.json and is unaffected. Removing a peer nothing imports is non-breaking for consumers. Considered marking the peer optional via peerDependenciesMeta instead (the manifest already uses that pattern for firebase-tools and platform-server); it would also avoid the ERESOLVE on npm, but it keeps advertising a dependency relationship that does not exist and relies on npm-specific resolver behavior. Deletion fixes every package manager. Refs #3667 (cherry picked from commit 8dfcc2c)

…uirement (#3662) (cherry picked from commit 8bf386e)

The optional firebase-tools peerDependency was capped at ^14.0.0, which excludes the current major (15.x). The ng add version check already accepts anything >= 14.0.0 and the schematic runs fine on 15.x, so the narrow range only produces spurious peer-dependency warnings for users on the current CLI. (cherry picked from commit 45f138d)

(cherry picked from commit 7576b5f)

…rated Cloud Functions (#3743) * fix(deploy): target Node 22 and the firebase-functions/v1 API in generated Cloud Functions The generated function declared engines.node 14, a runtime Cloud Functions decommissioned in early 2025, so it could not deploy at all. The gen 1 template also called functions.region() on the firebase-functions package root, which moved to the /v1 subpath in v6, so a deployed function crashed at cold start with TypeError: functions.region is not a function. Node 22 is the newest runtime Cloud Functions supports and satisfies the engines ranges of @angular/core and firebase-admin. Node 20 would deploy today, but its security support ended 2026-04-30. The same constant picks the Cloud Run base image, now node:22-slim. The docs example moves off the decommissioned functionsNodeVersion 12. * docs(site): update the functionsNodeVersion example in the site copy The site/ copy of the deploy guide still showed the decommissioned 12, flagged in review. Also fixes a spelling error on the same passage. * test(deploy): assert the generated template's require path and runtime Add two specs for what the earlier commit in this PR fixed: the gen 1 template requires firebase-functions/v1, and the default runtime is 22. Both specs fail when run against the old template. Also moves the /v1 comment above the export so it no longer reads like a parameter annotation.

…manifest (#3745) * fix(deploy): declare firebase-admin in the generated Cloud Functions manifest The root package.json had no firebase-admin entry, so the build resolved its version to undefined and JSON.stringify dropped it from the generated manifest. firebase-functions 6.x requires firebase-admin eagerly at module load, so the deployed function crashed at cold start wherever peers are not auto-installed (--legacy-peer-deps, yarn 1, pnpm). firebase-functions moves to ^6.1.1, the first release whose peer range accepts firebase-admin 13. * build: fail the build when a schematic dependency version is missing replaceSchematicVersions resolved versions from the root package.json with no check, and a missing entry was silently dropped from the shipped versions.json by JSON.stringify. That is how the generated Cloud Functions manifest lost firebase-admin (#3744). The build now throws, naming the package, and both loops share the guard.

v20's deploy schematics statically import versions.json, so esbuild inlines the source placeholders and 20.0.1 shipped version:"0.0.0" in the generated Cloud Functions manifest (ETARGET at install). The build now rewrites per-package placeholder tokens inside the emitted bundles and fails if any token survives. v20-only: main reads versions.json at runtime and never inlines it.

…ring ng add (#3714) * feat(schematics): generate .firebaserc and Firestore starter files during ng add ng add asks the user to pick a Firebase project but never records the choice, so every later firebase-tools command has no default project. It also leaves firebase.json empty and creates no security rules, so a Firestore-selected workspace cannot deploy rules at all. Now, after the project prompt, the schematic records the selection in .firebaserc (merging into an existing file rather than replacing it). When Firestore is selected it also generates firestore.rules and firestore.indexes.json — the same test-mode starter files that 'firebase init firestore' produces, with a warning that the rules expire in 30 days — and wires the firestore section into firebase.json. Existing rules files are left untouched. The new files go through the schematic Tree; firebase.json stays on the real filesystem because firebase-tools reads and rewrites it during the same run, and its firestore section is added only after those rewrites. * fix(schematics): move firestore starter files after init, widen error handling Tyler's review on #3714: createFirestoreStarterFiles staged the Tree before the DataConnect init calls, using a pre-init firebase.json snapshot. If a future init call ever added a firestore section mid-run, the stale snapshot would miss it and stage starter files on top of files firebase-tools already wrote to disk — the same Tree/disk collision the .firebaserc write hit earlier in this PR. Moved the call to run after init with a fresh re-read, and documented the more immediate invariant this enforces: it must run before addFirestoreToFirebaseJson, which is what adds the firestore section on a normal run. Also widened addFirestoreToFirebaseJson's try/catch to cover the firebase.json mutation and write, not just the read — a write failure (disk full, permissions) previously crashed with a raw Node error instead of the warn-and-continue the read path already gets. * fix(schematics): warn instead of crashing when the post-init firebase.json read fails The re-read added for the firestore starter files was unguarded, so a firebase.json that firebase-tools left unreadable would abort the whole ng add. Before the starter files moved after the init calls, this same failure degraded gracefully — the files were already staged, and addFirestoreToFirebaseJson warned and let setup finish. Restore that: warn and continue. createFirestoreStarterFiles independently checks the disk for each file it would create, so a missing snapshot costs the firestore-section check, not the collision safety it also relies on. Trimmed the surrounding comments to the two constraints a future edit could silently break — read after init, and run before addFirestoreToFirebaseJson — and moved the rationale here. The reason the read sits after the init calls at all: staging against a stale pre-init snapshot risks the Tree/disk collision the .firebaserc write hit earlier in this PR, where a Tree-staged file collides at commit time with one firebase-tools already wrote to disk and aborts the run. No init call adds a firestore section today, so that specific path is defensive against a future one.

#3717) * fix(schematics): warn when ng add setup runs with no features selected Pressing Enter without toggling any checkbox at the features prompt silently exited with the CLI's stock "Nothing to be done." message, giving no indication that Space selects a feature. Print a warning explaining the checkbox controls and inviting a retry. * refactor(schematics): derive the empty-features warning from the prompt message The empty-features warning duplicated the checkbox prompt's message as a second string literal, so a reworded prompt would leave the warning pointing at text the user never sees. Export the message as a shared constant and reference it in both places, matching the shared-constant pattern used for the firebase-tools version message in 59c8a2f.

Navigation Menu

Uh oh!

Comparing changes

Open a pull request

Uh oh!

Commits on Aug 12, 2026

This comparison is taking too long to generate.

Uh oh!