chore(firestore-bigquery-change-tracker): release 2.2.0, run on firebase-admin 14 - #3134
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the change-tracker package to version 2.1.2, migrating from the deprecated namespaced firebase-admin API to the modular API to ensure compatibility with firebase-admin v14. It also widens the firebase-functions dependency range to support version 7. Feedback was provided on a test file where calling getFirestore() at the top level is fragile and could crash if imports are reordered; initializing it inside a beforeAll block is recommended instead.
407341c to
9ec2103
Compare
…ase-admin 14 firebase-admin 14 removes the namespaced API. The package still read admin.apps at import and admin.firestore.Timestamp in the partition converter, so it crashed on 14 despite 2.1.1 accepting it. Every use is now the modular API, which works on 13 and 14. firebase-functions 6 peer-pins firebase-admin to 13, so a consumer on 14 kept a second nested admin copy under this package however wide its own range was. The range now accepts firebase-functions 7 as well; the package only uses its logger.
9ec2103 to
9173c25
Compare
|
Nit, non-blocking: this goes out as a patch, but it widens a runtime dependency range. A consumer that pins neither dep and resolves fresh moves to |
|
Nit, non-blocking: the lockfile deliberately stays on admin 13 / functions 6 (the ESM |
|
Nit, non-blocking, for #3127 rather than here: the kit still uses the namespaced entry point, so the same import-time crash just moves up a level once it resolves against admin 14.
24: import * as admin from "firebase-admin";
...
73: if (admin.apps.length === 0) {
74: admin.initializeApp();It already imports |
…se-functions at 7.3.0 backupSettings.test.ts mocked firebase-admin/app without getApps, so the migrated guard threw at import and all 12 tests failed. firebase-functions 7.0 through 7.2 still peer-pin firebase-admin to 13; 7.3.0 is the first release whose peer range includes 14. Accepting only ^7.3.0 makes the single-admin resolution a property of the range.
…gines floor Widening the runtime dependency ranges moves the versions a fresh, unpinned resolve picks, so this ships as a minor rather than a patch. engines.node >=18 states the floor firebase-admin 13 already imposed.
cabljac
changed the title
|
Taken: now 2.2.0, with engines.node >=18 (the floor firebase-admin 13 already imposed, so not a new constraint). Changelog updated. |
|
On the third nit: that snippet is the legacy extension ( |
|
On the CI point: tracked in #3136. The gap is wider than the admin 14 path, the package is not in the root jest projects list at all, and its partitioning e2e suite has 8 pre-existing failures on next. |
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.
3 participants
Follow-up to #3133. 2.1.1 widened the firebase-admin range to
^13.2.0 || ^14.0.0but two things stopped it working on 14.First, firebase-admin 14 removes the namespaced API. The package still read
admin.appsat import inhandleFailedTransactionsandadmin.firestore.Timestampin the partition converter, so wherever it resolved against admin 14 it threwCannot 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 fromfirebase-admin/appandfirebase-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.appsresolved on the nested 13. The range now accepts firebase-functions 7 as well; the package only uses itslogger.Verified: build and the test tsconfig compile against admin 14.3.0 and functions 7.3.2;
converter.test.tspasses (48) on that tree; the packed tarball installed into the firestore-bigquery-export kit on admin 14, followed bynpm 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
josethat firebase-functions v2 pulls in via admin auth; that is a jesttransformIgnorePatternsgap for a separate change. The live BigQuery suites were not run.Unblocks the kit bump in #3127.