fix(extensions): skip extensions deploy when there is nothing to deploy

[IzaakGough]

Fixes #7584.

Problem

firebase deploy --only functions on a codebase with no extensions still runs the extensions deploy stage, and the first thing that stage does is check the Cloud Billing API. Under Workload Identity or a service account that fails with a 403, since ADC carries no quota project and Cloud Billing usually is not enabled on the target project.

The chain:

1. The functions SDK always emits an extensions record in the manifest, {} when there are none.
2. v1alpha1.ts does if (manifest.extensions), so an empty record still sets build.extensions = {}, which is truthy.
3. functions/prepare.ts therefore calls prepareDynamicExtensions, which returns early when nothing is declared and nothing exists remotely, but prepare.ts assigns context.extensions and payload.extensions anyway.
4. functions/deploy.ts gates on payload.extensions && context.extensions, and {} && {} is truthy, so extensions deploy runs against an empty plan and calls checkBilling.

extensions/release.ts already guards against an empty payload. extensions/deploy.ts does not, which is what lets this through.

Fix

• functions/prepare.ts: only pass the extensions context and payload on when prepareDynamicExtensions reports that it built a plan. It now returns a boolean rather than leaving the caller to infer this from the payload contents.
• extensions/deploy.ts: return early when there is nothing to create, update, configure or delete, before the billing check. release has a similar guard, though it tests for the payload fields being absent rather than empty.

The Extensions API check and firebaseextensions.instances.list stay on the deploy path, since those are what detect extensions deleted from code, and they already fail soft. Worth noting that the Billing API is not needed for that detection: nothing in the prepare or list path calls Cloud Billing, so the empty-payload deploy stage was the only thing requiring it.

Testing

New extensions/deploy.spec.ts covers empty payload, all-empty lists, create, delete-only and configure. The two no-op cases fail without this change. Cases that should proceed assert they reached bulkCheckProductsProvisioned, so widening the guard cannot silently turn a real deploy into a no-op. Added a case to extensions/prepare.spec.ts pinning the early-return contract that functions/prepare now depends on. Existing suites for deploy/extensions and deploy/functions pass (104 tests), tsc --noEmit and eslint are clean.

[gemini-code-assist]

Code Review

This pull request resolves an issue where deploying functions from a codebase with no extensions incorrectly required the Cloud Billing API to be enabled. It updates the deployment flow to skip billing checks when there are no extensions to create, update, or configure, and adds comprehensive unit tests. The review feedback suggests two key improvements: first, refining the payload check in prepare.ts to explicitly check the lengths of the instance lists rather than using Object.keys(), which can be misleadingly truthy; second, replacing the use of any with the proper Options type in the test suite to align with the repository's TypeScript style guidelines.

[gemini-code-assist]

Instead of checking Object.keys(extPayload).length, which can be truthy (e.g., 4) even when all the deployment lists are empty arrays (e.g., []), we should explicitly check if there is at least one instance to create, configure, update, or delete. This prevents passing an empty payload to subsequent stages.

    if (
      extPayload.instancesToCreate?.length ||
      extPayload.instancesToConfigure?.length ||
      extPayload.instancesToUpdate?.length ||
      extPayload.instancesToDelete?.length
    ) {

[gemini-code-assist]

Avoid using any as an escape hatch for the options variable, as it violates the repository style guide (TypeScript section, line 37). Instead, import Options from ../../options and cast the mock object as Options.

Suggested change

	import { expect } from "chai";
	import * as sinon from "sinon";
	import { deploy } from "./deploy";
	import { Context, Payload } from "./args";
	import * as cloudbilling from "../../gcp/cloudbilling";
	import * as provisioningHelper from "../../extensions/provisioningHelper";
	describe("Extensions deploy", () => {
	let checkBillingEnabledStub: sinon.SinonStub;
	let bulkCheckProductsProvisionedStub: sinon.SinonStub;
	const options: any = { nonInteractive: true, project: "test-project" };
	import { expect } from "chai";
	import * as sinon from "sinon";
	import { deploy } from "./deploy";
	import { Context, Payload } from "./args";
	import * as cloudbilling from "../../gcp/cloudbilling";
	import * as provisioningHelper from "../../extensions/provisioningHelper";
	import { Options } from "../../options";
	describe("Extensions deploy", () => {
	let checkBillingEnabledStub: sinon.SinonStub;
	let bulkCheckProductsProvisionedStub: sinon.SinonStub;
	const options = { nonInteractive: true, project: "test-project" } as Options;

References

1. Never use any or unknown as an escape hatch. Define proper interfaces/types or use type guards. ^(link)