fix(deploy): target Node 22 and the firebase-functions/v1 API in generated Cloud Functions

[armando-navarro]

Checklist

• Issue number for this PR: ng deploy generates a Cloud Function that targets the decommissioned Node 14 runtime and crashes on firebase-functions 6 #3742 (required)
• Docs included?: yes
• Test units included?: no. The existing Node suite passes (117 specs). The change is to generated-code templates with no spec file today, and it was verified by generating the function from the built templates and loading it against a real firebase-functions 6 install: the old template throws TypeError: functions.region is not a function, the fixed one loads.
• In a clean directory, yarn install, yarn test run successfully?: yes

Description

Fixes #3742.

Three fixes to what ng deploy generates for Cloud Functions:

• DEFAULT_NODE_VERSION goes from 14 to 22.
  • Node 14 was decommissioned by Cloud Functions in early 2025, so the generated function could not deploy at all.
  • 22 is the newest runtime Cloud Functions supports.
  • It satisfies the engines ranges of @angular/core (^20.19.0 || ^22.12.0 || >=24.0.0) and firebase-admin (>=18).
  • Node 20 would also deploy today, but its security support ended 2026-04-30.
  • The same constant picks the Cloud Run base image, so that path moves from the stale node:14-slim to node:22-slim.
• The gen 1 template requires firebase-functions/v1.
  • On firebase-functions 6 the v1 API moved off the package root, so the generated functions.region(...) call threw TypeError: functions.region is not a function on cold start.
  • The /v1 subpath is present on both firebase-functions 6 and 7.
• The docs example asks for functionsNodeVersion: 22 instead of the decommissioned 12.

These defects also affect the v20 line and are planned for cherry-pick onto the 20.0.x release branch after this lands.

[tyler-reitz]

LGTM, approving. Three non-blocking notes.

site/src/get-started/deploying.md:107 still has the same example at "functionsNodeVersion": 12. Nothing in .github/workflows builds site/, so it's not a deploy risk, but it's the other half of the docs fix.

The new comment above require('firebase-functions/v1') sits inside the parameter list, between functionName and ) =>. Legal, but it scans as a parameter annotation. Above export const defaultFunction would read better.

On tests: asserting defaultFunction(...) contains firebase-functions/v1 goes red against the old template and green against this one (verified the substring both ways). Cheap insurance before the 20.0.x cherry-pick.

One claim I couldn't check: firebase-admin engines >=18, since the package isn't installed until #3745 lands. Inference on my side, worth confirming before the cherry-pick.

Confirmed the core fix locally against firebase-functions 6.5.0: require('firebase-functions').region is undefined, require('firebase-functions/v1').region is a function.

[tyler-reitz]

Correcting one thing from my review above: I flagged the firebase-admin engines >=18 claim as unverified. It checks out. firebase-admin 13.0.0 through 13.10.0 all declare node: ">=18", so Node 22 satisfies the whole ^13.0.0 range the manifest will pin once #3745 lands. Nothing to change here, and nothing to re-check before the 20.0.x cherry-pick.

[armando-navarro]

Thanks for the careful pass, and for checking the v1 claim against a real install.

All 3 of your suggestions are implemented now:

• The site/ copy of the example now says 22 as well, plus a spelling fix on the same passage.
• The comment now sits above export const defaultFunction. I agree it reads better there.
• I added a spec covering both things this PR changes: the gen 1 template requires firebase-functions/v1, and the default runtime is 22.