Generated banner for Extension To Functions Codebase
Generated logo for Extension To Functions Codebase

Extension To Functions Codebase

Firebase (Google)OfficialCreated by Google LLCDistributed by Firebase (Google)

  • Skill
  • Workflow
  • Cloud and DevOps
  • Apache-2.0
  • No issues found

From the author

Skill for converting an installed Firebase Extension (or extension source) into a standalone Cloud Functions for Firebase codebase or publishable npm package, including V1 to V2 trigger upgrades, lifecycle hooks, and declarative security
— the description by Google LLC

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured process for converting Firebase Extensions into either a local Cloud Functions codebase for direct application integration or a publishable npm package for reuse. It emphasizes modernizing legacy V1 triggers to V2, implementing declarative IAM and API management, and utilizing the Destructuring Compatibility Shim to preserve existing business logic during the transition.

What it does

  • Converts extension configuration parameters into modern defineString, defineInt, and defineSecret declarations.
  • Upgrades V1 Cloud Functions triggers to V2 using the Destructuring Compatibility Shim.
  • Maps extension lifecycle events to SDK lifecycle hooks like afterFirstDeploy and afterRedeploy.
  • Configures package.json for reusable npm distribution with proper peer dependencies and exports.
  • Implements declarative IAM roles and API requirements directly within the codebase.
  • Generates documentation including installation instructions and configuration references.

When to use it

  • When you need to move from a managed Firebase Extension to a custom, maintainable codebase.
  • When you want to share extension logic across multiple projects as a reusable npm package.
  • When you need to modernize legacy V1 functions to V2 while preserving complex internal logic.
  • When you want to replace manual gcloud scripts with declarative infrastructure-as-code.

Advantages

  • Preserves existing business logic through the use of the Destructuring Compatibility Shim.
  • Reduces local configuration overhead by using native SDK declarations for IAM and APIs.
  • Enables modern V2 features like increased concurrency and improved runtime options.
  • Provides a clear path for creating shareable, version-controlled function packages.

Usage examples

“Migrate my installed Firebase Extension to a local functions codebase.”
The agent will inventory your extension.yaml, map parameters to define functions, upgrade triggers to V2, and structure the code in functions/src/.
“Convert this extension into a reusable npm package.”
The agent will configure your package.json, set up the exports map, and generate a README for consumers to re-export your functions.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/firebase/extension-to-functions-codebase/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip extension-to-functions-codebase.zip -d .agents/skills

Documentation by Google LLC

Extension to Functions Codebase & npm Package Migration

Overview

Migrates a Firebase Extension into either:

  1. A local Cloud Functions codebase (functions/src/ for app integration).

  2. A publishable npm package (reusable open-source package exporting V2 functions).

Leverages native Cloud Functions features (declarative IAM, Parameterized Config, SDK Lifecycle Hooks) and modernizes 1st Gen triggers to 2nd Gen using the Destructuring Compatibility Shim.


Target Migration Workflows

  • Target A: Local Functions Codebase (End-User App Integration)

    • Output: Code under functions/src/. Config in .env.

    • Deployment: firebase deploy --only functions.

  • Target B: Publishable npm Package / Shareable Package

    • Output: Reusable npm package exporting V2 functions.

    • Configuration: package.json specifying exports map, engines: { "node": ">=22" }, and peerDependencies: { "firebase-functions": ">=6.0.0" }.

    • Usage: Consumers install package and re-export functions in index.ts (export * from "<package-name>").


Core Rules & Constraints

1. Declarative IAM & APIs (Zero-Local-Overhead)

Use native SDK declarations instead of manual gcloud scripts or console instructions:

  • Use requiresRole("roles/...") for required GCP IAM permissions.

  • Use requiresAPI("service.googleapis.com", "Description") for Google APIs.

2. Global Parameter Access Restriction
  • Never call .value() at top-level module load scope.

  • Initialize global SDK instances inside onInit() or lazy getters:

    import { defineString } from "firebase-functions/params";
    import { onInit } from "firebase-functions/v2";
    
    const dataset = defineString("DATASET_ID");
    let client: BigQuery;
    
    onInit(() => {
      client = new BigQuery({ datasetId: dataset.value() });
    });
3. V2 Concurrency & Cost Parity

V2 enables concurrency (up to 80 requests). To preserve V1 single-concurrency pricing, set cpu: "gcf_gen1".


Step-by-Step Migration Execution

Step 1: Inventory Extension Resources
  1. extension.yaml:

    • params → defineString, defineInt, defineBoolean, defineSecret.

    • apis → requiresAPI(...).

    • roles → requiresRole(...).

    • lifecycleEvents → afterFirstDeploy & afterRedeploy.

    • resources → Upgrade 1st Gen triggers to 2nd Gen (onDocumentWritten, onTaskDispatched, onRequest).

  2. Files & Scripts: Preserve devDependencies, test framework (jest), and test scripts.

Step 2: Configure package.json
  • Set name: "<package-name>", engines: { "node": ">=22" }.

  • Set peerDependencies:

    "peerDependencies": {
      "firebase-admin": "^11.0.0 || ^12.0.0",
      "firebase-functions": ">=6.0.0"
    }
  • Configure exports map targeting ESM/CommonJS and TypeScript declarations (lib/index.js, lib/index.d.ts).

Step 3: Upgrade Triggers from V1 to V2
  • Firestore: Use onDocumentWritten from firebase-functions/v2/firestore.

  • Tasks: Use onTaskDispatched from firebase-functions/v2/tasks. Remove EXT_INSTANCE_ID when enqueueing tasks.

  • HTTP: Use onRequest from firebase-functions/v2/https.

  • Apply Destructuring Compatibility Shim ({ change, context }, { snapshot, context }) where legacy 1st Gen handlers expect (change, context).

Step 4: Convert Lifecycle Events

Map extension lifecycle events to SDK lifecycle hooks in src/index.ts:

  • onInstall → afterFirstDeploy({ task: { function: "initTask" } })

  • onUpdate / onConfigure → afterRedeploy({ task: { function: "setupTask" } })

Step 5: Package README & Export Instructions

Generate README.md containing:

  1. Installation instructions (npm install).

  2. Re-export snippet (export * from "<package-name>").

  3. Parameterized Configuration .env reference table.

  4. What Changed (Extension vs Package) comparison table.

Reminder: NEVER execute npm publish.

Files

references/configuration-migration.md

Migrating Runtime Configurations (runWith)

In Cloud Functions for Firebase V1 (firebase-functions/v1), you configured runtime settings like memory, timeout, and service accounts using .runWith(). In V2 (firebase-functions/v2), .runWith() is removed and replaced by a more flexible options system.

You can configure V2 functions in two ways: Per-Function (passing an options object directly to the trigger) or Globally (setGlobalOptions at the top of a file).


1. Per-Function Configuration

Pass the configuration options object as the first argument to the V2 trigger function. Per-function options always override any global defaults.

V1 Legacy
import * as functions from "firebase-functions";

export const processOrder = functions
  .runWith({ memory: "2GB" })
  .pubsub.topic("orders")
  .onPublish((message, context) => { ... });
V2 Modern Equivalent
import { onMessagePublished } from "firebase-functions/v2/pubsub";

export const processOrder = onMessagePublished(
  {
    topic: "orders",
    memory: "2GiB", // Options passed as the first argument!
  },
  ({ message, context }) => { ... } // Destructuring shim pattern
);

[!TIP] Memory Unit Caveat: V1 accepted "1GB". V2 types strongly prefer IEC units like "1GiB", "2GiB", etc.


2. Global Configuration (setGlobalOptions)

Use setGlobalOptions at the top of your file when all or most functions in that file share the exact same runtime requirements (e.g. identical region, memory allocation, timeout, or service account). Individual functions can still override specific settings by declaring per-function options.

V1 Legacy
import * as functions from "firebase-functions";

export const myFn = functions
  .runWith({
    memory: "1GB",
    timeoutSeconds: 120,
    serviceAccount: "[email protected]",
  })
  .https.onRequest((req, res) => { ... });
V2 Modern Equivalent
import { setGlobalOptions } from "firebase-functions/v2";
import { onRequest } from "firebase-functions/v2/https";

// Set global defaults for all functions defined after this call in this file
setGlobalOptions({
  memory: "1GiB", // Note: GiB instead of GB is preferred in V2 types
  timeoutSeconds: 120,
  serviceAccount: "[email protected]",
});

export const myFn = onRequest((req, res) => { ... });

Common Property Translations

V1 PropertyV2 PropertyNotes
memorymemoryUse "1GiB" instead of "1GB".
timeoutSecondstimeoutSecondsSame.
ingressSettingsingressSettingsSame.
vpcConnectorvpcConnectorSame.
vpcConnectorEgressSettingsvpcConnectorEgressSettingsSame.
serviceAccountserviceAccountSame.
secretssecretsSame.
failurePolicyretryRenamed to boolean retry: true/false in V2 Eventarc triggers.

3. Migrating Environment Configurations (functions.config())

In V1, you used functions.config() to access environment configuration. In V2, this is replaced by Parameterized Configuration.

Deterministic Rules for Migration

Follow these rules to ensure a deterministic and safe migration:

Typing & Exports
  • Numbers: If the value is used as a number, use defineInt or defineNumber.

  • Secrets: If the key contains "KEY", "SECRET", "TOKEN", or "PASSWORD", use defineSecret() or defineJsonSecret().

    • Note: Secrets MUST be explicitly bound to the function that uses them in the options object (e.g., { secrets: [myKey, myJsonSecret] }). Both SecretParam and JsonSecretParam are supported in the secrets array.

  • Lists: Use defineList for comma-separated lists.

  • JSON: Use defineJSON for JSON strings.

  • Buckets: If the param is a storage bucket, set input: { text: {} } or bucket selector.

  • Input Validation: Use nonEmpty: true inside input.text or input.multiSelect to enforce non-empty parameter input during CLI prompting (e.g. defineString("PARAM", { input: { text: { nonEmpty: true } } })).

  • Type Annotations: Import parameter types directly from firebase-functions/params (e.g. import type { StringParam, SecretParam, JsonSecretParam, IntParam } from "firebase-functions/params").

Initialization & Scope
  • Global Initialization: If a variable was initialized globally in V1 (e.g., const client = new Client(functions.config().key)), you must split it to have declaration at global scope and initialization inside onInit:

    import { onInit } from "firebase-functions/v2";
    
    const myKey = defineSecret("MY_KEY");
    let client: Client;
    
    onInit(() => {
      client = new Client(myKey.value());
    });
Advanced Interpolation & Logic
  • String Interpolation: Use the expr tagged template literal from firebase-functions/params (e.g., `expr`every ${period} days`) instead of standard template literals when constructing dynamic strings with parameters. Do NOT call .value() inside expr.

  • Logic Operators: Use expressions like projectID.equals('prod').thenElse(1, 0) for logical operations instead of ternary operators on .value().

Built-ins
  • Prefer built-in variables like databaseURL, projectID, gcloudProject, storageBucket rather than defining new params for these values.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Google LLC
Publisher
Firebase (Google) (Official)
Distributed by
Firebase (Google)
Source
firebase/agent-skills · skills/extension-to-functions-codebase · commit b76be96
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Google LLC or Firebase (Google).

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download extension-to-functions-codebase.zip