extension-to-functions-codebase
Skill506 starsChanged 5 months agoApache-2.0View on GitHub
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
- Reads credentials
In this repository13 other files it gives its agents.
- firebase-ai-logic-basicsSkill
- firebase-analyticsSkill
- firebase-app-hosting-basicsSkill
- firebase-auth-basicsSkill
- firebase-basicsSkill
- firebase-crashlyticsSkill
- firebase-data-connectSkill
- firebase-firestoreSkill
- firebase-hosting-basicsSkill
- firebase-remote-config-basicsSkill
- firebase-security-rules-auditorSkill
- firestore-rules-creationSkill
- xcode-project-setupSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 0 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 47
Use native SDK declarations instead of manual gcloud scripts or console instructions:
- Very specific: line 50
Use requiresRole("roles/...") for required GCP IAM permissions.
- Very specific: line 51
Use requiresAPI("service.googleapis.com", "Description") for Google APIs.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Extension to Functions Codebase & npm Package Migration
Overview
Migrates a Firebase Extension into either:
- A local Cloud Functions codebase (
functions/src/for app integration). - 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.
- Output: Code under
Target B: Publishable npm Package / Shareable Package
- Output: Reusable npm package exporting V2 functions.
- Configuration:
package.jsonspecifyingexportsmap,engines: { "node": ">=22" }, andpeerDependencies: { "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
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).
- 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
exportsmap targeting ESM/CommonJS and TypeScript declarations (lib/index.js,lib/index.d.ts).
Step 3: Upgrade Triggers from V1 to V2
- Firestore: Use
onDocumentWrittenfromfirebase-functions/v2/firestore. - Tasks: Use
onTaskDispatchedfromfirebase-functions/v2/tasks. RemoveEXT_INSTANCE_IDwhen enqueueing tasks. - HTTP: Use
onRequestfromfirebase-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:
- Installation instructions (
npm install). - Re-export snippet (
export * from "<package-name>"). - Parameterized Configuration
.envreference table. - What Changed (Extension vs Package) comparison table.
Reminder: NEVER execute npm publish.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

