chore(firestore-bigquery-change-tracker): release 2.1.1, accept firebase-admin 14 - #3133
Merged
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates @firebaseextensions/firestore-bigquery-change-tracker to version 2.1.1, expanding the firebase-admin dependency range to support both version 13 and 14 (^13.2.0 || ^14.0.0). The review feedback points out that the package-lock.json file is out of sync with package.json because the updated dependency range is not reflected in the lockfile, and recommends running npm install to regenerate it.
cabljac
force-pushed
the
chore/tracker-admin-14-release
branch
from
September 7, 2026 14:40
033272d to
a8f962b
Compare
cabljac
added a commit
that referenced
this pull request
Sep 7, 2026
…ase-admin 14 (#3134) Follow-up to #3133. 2.1.1 widened the firebase-admin range to `^13.2.0 || ^14.0.0` but two things stopped it working on 14. First, firebase-admin 14 removes the namespaced API. The package still read `admin.apps` at import in `handleFailedTransactions` and `admin.firestore.Timestamp` in the partition converter, so wherever it resolved against admin 14 it threw `Cannot read properties of undefined (reading 'length')` at import. Every namespaced use, in shipped code, the test fixture and the tests, is now the modular API from `firebase-admin/app` and `firebase-admin/firestore`, which is identical on 13 and 14. Second, the package depends on firebase-functions `^6.3.2`, whose peer range for firebase-admin stops at `^13.0.0`. On a consumer running admin 14 npm therefore kept a nested admin 13 under the tracker regardless of the tracker's own range, and that nested copy has no default app. Under npm that nesting is also why 2.1.1 did not crash: `admin.apps` resolved on the nested 13. The range now accepts firebase-functions 7 as well; the package only uses its `logger`. Verified: build and the test tsconfig compile against admin 14.3.0 and functions 7.3.2; `converter.test.ts` passes (48) on that tree; the packed tarball installed into the firestore-bigquery-export kit on admin 14, followed by `npm dedupe`, collapses to a single admin copy, the tracker resolves the kit's app, and all 62 kit tests pass. An existing consumer shrinkwrap does not dedupe on its own, since the nested 13 still satisfies the new ranges, so the kit bump must dedupe explicitly. The kit pins firebase-functions `^7.3.3-rc.0`, which no stable range matches, so a nested firebase-functions 7.3.2 remains under the tracker until the kit moves to a stable 7.x; that only affects trace correlation on tracker log lines, not the admin app. The lockfile stays on admin 13 and functions 6 because under admin 14 the jest config cannot load the ESM-only `jose` that firebase-functions v2 pulls in via admin auth; that is a jest `transformIgnorePatterns` gap for a separate change. The live BigQuery suites were not run. Unblocks the kit bump in #3127.
cabljac
added a commit
that referenced
this pull request
Sep 8, 2026
First layer of the Cloud Tasks write buffer stack. Bumps firebase-admin from ^13.6.0 to ^14.2.0 and the change tracker from ^2.1.0 to ^2.2.1, regenerates the shrinkwrap, and adds one override; no source changes. The admin bump also moves `@google-cloud/firestore` from 7.11.6 to 8.7.1, a major on the client the tracker's backup writes go through. The next layers enqueue onto a task queue by bare function name. firebase-admin 14.2.0 resolves the deployed `kit-<instance id>-` prefix itself from `FIREBASE_KIT_INSTANCE_ID`, which the Firebase CLI sets on every deployed kit function from 15.28.0, so the kit does not have to reconstruct the prefix. Tracker 2.2.0 (#3133, #3134) is the first release that runs on firebase-admin 14: earlier versions pinned admin 13 and used the namespaced API, so npm nested a second admin copy under the tracker with no default app and every backup write failed. 2.2.1 (#3137) adds the view-update project fix from #3120. The shrinkwrap now holds a single `firebase-admin@14.3.0`, verified by resolving `firebase-admin/firestore` from the tracker's directory and calling `getFirestore` after the kit's `initializeApp`. The kit pins `firebase-functions ^7.3.3-rc.0`, which no stable range in the tracker can match, so a root `overrides` entry pins the tracker's firebase-functions to the kit's own; the shrinkwrap holds a single `firebase-functions@7.3.3-rc.0` as well, so tracker log lines keep the kit's trace context. That single-copy guarantee reaches consumers through the published shrinkwrap and holds for npm installs only: npm ignores `overrides` from a non-root package, and pnpm and yarn ignore a dependency's `npm-shrinkwrap.json`, so they resolve the tracker's `^6.3.2 || ^7.3.0` to a second firebase-functions copy. 62 unit tests and `tsc -b` pass on this layer; 89 on the top of the stack. The top of the stack was also deployed to a test project with Firebase CLI 15.29.0: `afterFirstDeploy` provisioned the dataset, changelog table, and view; create, update, and delete events landed in the changelog; a redeploy exercised the update-view path with the project preserved; and with the changelog table removed, the trigger enqueued onto `syncBigQuery`, the tracker wrote backup documents through admin 14 / firestore 8.7.1, and the queue drained without duplicate rows once the table was re-provisioned. Part of #3031.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The change tracker pins
firebase-adminto^13.2.0. A consumer on firebase-admin 14 therefore installs a second copy of the SDK nested under the tracker, and that copy has its own app registry: the consumer'sinitializeApp()never reaches it. Every call the tracker makes through its own copy, which today is the backup write inhandleFailedTransactions, fails with "The default Firebase app does not exist", the failure is logged asfailedBackupWrite, and the rows meant forbackupTableIdare lost. Verified by loading both copies in one process against the published 2.1.0.The range was already widened to
^13.2.0 || ^14.0.0on thekitsbranch (cc86630) but that landed at 2.0.4 and was never published; 2.1.0 was cut fromnextwithout it. This cherry-picks that commit ontonextand releases it as 2.1.1 with a changelog entry. No source changes: the tracker only usesgetFirestore,firebase-admin/appandTimestamp, all unchanged between 13 and 14, and the firebase-functions 6 it depends on already accepts admin 14.npm ciandnpm run buildpass. The jest suite needs live BigQuery and was not run.Unblocks the kit bump in #3127.