Skip to content

Kits parity issues #2974

Description

@CorieW

Below are comments for each extension to kit migration. Each comment displays the differences between the extension and the corresponding kit.

Valid differences

  • Some changes are due to migrations from gen1 functions to gen2. These specific changes have been excluded from the comments below.
  • yes / no params changed to booleans (with defineBoolean) in kits.
  • Service account params have been removed in kits, as they conflict with declarative security (requiresRole) stuff.
  • LOCATION params have been removed in kits, as kits builds this feature in.
  • Some changes may be due to dependency upgrades, or more recent Node versions.
  • Extensions previously didn't support a number type, so they used text/string type with regex (e.g. validation: ^[0-9]) for validation. Kits now use defineInt, so they don't require the regex validation.
  • required: defaults to true when omitted in extension.yaml, and several extensions omit it on params their own code and descriptions treat as optional (BACKUP_COLLECTION, DEFAULT_REPLY_TO, USERS_COLLECTION, TEMPLATES_COLLECTION). Kits match the code behaviour (optional, empty → undefined), not the yaml.
  • defineSecret cannot be optional — SecretParamOptions only takes label/description, so any bound secret must exist at deploy. Extension params declared type: secret, required: false (API_KEY, GOOGLE_AI_API_KEY, GEMINI_API_KEY, OPENAI_API_KEY, and the send-email SMTP/OAuth secrets) therefore become mandatory-at-deploy in kits. Platform constraint, not a kit choice.
  • Where an extension's yaml default disagreed with its own code fallback (firestore-genai-chatbot / firestore-vector-search COLLECTION_NAME, delete-user-data AUTO_DISCOVERY_SEARCH_FIELDS), kits standardise on the yaml default.
  • No firebase-functions/params equivalent of the ${DATABASE_INSTANCE} system param. In the extension, the built-in FIREBASE_CONFIG.databaseURL resolves without prompting. This is something kit has to handle itself. Only applicable in rtdb-limit-child-nodes extension/kit.
  • IMG_BUCKET / EXTENSION_BUCKET use the params BUCKET_PICKER (a ResourceInput), which cannot also carry a validationRegex or example, so those two params keep the picker instead of the extensions' regex and example. The picker constrains input to real buckets, which is stronger, and this will stay as is.
  • Function resource properties (timeout, memory, maxInstances from each extension's resources[].properties) have not been systematically compared against the kit function definitions, and no sweep is planned — this may be something firebase-tools handles itself when deploying kits.
  • Kits have no deploy-time status surface. Extensions reported progress and failures through getExtensions().runtime().setProcessingState(...); nothing equivalent exists for kits, so deploy-time outcomes are only visible in function logs. Affects bigquery-firestore-export (10 call sites), firestore-bigquery-export (lifecycle hooks), firestore-translate-text (backfill) and firestore-vector-search (backfill gating).
  • billingRequired: true has no kit equivalent, so kits cannot declare the billing requirement that firestore-translate-text and rtdb-limit-child-nodes declared in their yaml.
  • rtdb-limit-child-nodes renamed NODE_PATH to RTDB_NODE_PATH and will keep it: Node.js reserves NODE_PATH for module resolution, so the original name is overwritten at runtime.
  • Event payload shapes changed with the gen1 to gen2 migration: { change, context } became { data, params } (firestore-counter, firestore-translate-text), and speech-to-text now publishes { message, stack } where the extension published a non-enumerable Error that serialised to {}. Consumers reading context.params need updating.
  • firestore-vector-search publishes Eventarc events where the extension published none (it declared the event types in extension.yaml but never published them). The kit exceeds the extension here rather than falling short.
  • extension.yaml used to have a reason for roles and APIs. Now with kits, only requiresAPI accepts a reason param. requiresRole doesn't accept a reason.

Look into

Remaining parity work

Correctness / production-firing

Migration / consumer breaks

Events gaps

Behavior divergence (fix or decide)

Feature-scale (design first)

Notes candidates (won't fix — differences to justify in Notes instead)

Minor / cosmetic (batchable)

Completed

Correctness / production-firing

Migration / consumer breaks

Events gaps

Behavior divergence (fix or decide)

Feature-scale (design first)

Notes candidates (won't fix — differences to justify in Notes instead)

  • rtdb-limit-child-nodes: NODE_PATH rename (Node.js reserves the name)

Minor / cosmetic (batchable)

Coverage

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions