Skip to content

fix(core): raise the rxfire floor to ^6.2.0 for its firebase 12 peers#3723

Open
armando-navarro wants to merge 1 commit into
angular:mainfrom
armando-navarro:rxfire-620-floor
Open

fix(core): raise the rxfire floor to ^6.2.0 for its firebase 12 peers#3723
armando-navarro wants to merge 1 commit into
angular:mainfrom
armando-navarro:rxfire-620-floor

Conversation

@armando-navarro

Copy link
Copy Markdown
Collaborator

rxfire 6.2.0 shipped to npm latest on July 22, 2026 with firebase 12 in its peer range (FirebaseExtended/rxfire#152). This PR raises our dependency floor to require it.

Background

  • rxfire 6.1.0 accepts firebase ^9 || ^10 || ^11 as peers. @angular/fire on main depends on firebase ^12.4.0, so a tree holding rxfire 6.1.0 gets a second firebase 11 installed next to firebase 12 (or, at best, an invalid-peer marker).
  • Two installed SDK copies fail each other's instance checks at runtime; the first Firestore read throws Type does not match the expected instance. Did you pass a reference from a different Firestore SDK?.
  • rxfire 6.2.0 widens the peer range to ^9 || ^10 || ^11 || ^12 and contains no other runtime change (the only other commit between 6.1.0 and 6.2.0 is CI-only).

What this changes

  • src/package.json: rxfire ^6.1.0 to ^6.2.0 (the range the published package ships).
  • root package.json: the same bump, and removes the overrides block that forced rxfire's firebase peer to ^12.4.0 in this repo's own install tree; rxfire 6.2.0 makes it unnecessary.
  • package-lock.json: rxfire moves to 6.2.0; npm also synced the lockfile's stale root version 21.0.0-next.0 to 21.0.0-rc.0, matching package.json.

Why raise the floor when ^6.1.0 already resolves to 6.2.0

Fresh installs are unaffected: a clean project installing @angular/fire@21.0.0-rc.0 today already resolves rxfire 6.2.0 and a single firebase (verified). The floor is for upgrades: a lockfile that pins rxfire 6.1.0 satisfies ^6.1.0, survives an @angular/fire upgrade, and rxfire 6.1.0's peer set then re-creates the duplicate firebase 11. With ^6.2.0 the upgrade is forced onto the fixed release.

What this does not fix

An app whose own firebase dependency stays on 11.x still ends up with two SDK copies: rxfire binds the root firebase 11 while @angular/fire nests firebase 12. That is the mechanism behind #3684, #3681, and #3682, and the fix there is upgrading the app's firebase to ^12 together with @angular/fire; a schematics follow-up and the release notes will cover that path. Refs #3666.

Verification

  • Clean-project install of 21.0.0-rc.0: resolves rxfire 6.2.0, one firebase@12.16.0 (rxfire's copy deduped), one @firebase/firestore.
  • Repo tree after the change: rxfire 6.2.0, single firebase, no nested copy under rxfire.
  • npm run build: the packed tarball's package.json carries rxfire: ^6.2.0.

rxfire 6.1.0 peers firebase ^9||^10||^11, so npm installs a second
firebase 11 next to @angular/fire's firebase 12 and the first Firestore
read throws "Type does not match the expected instance". rxfire 6.2.0
(the peer-range fix, rxfire#152) is on npm latest since 2026-07-22.

^6.1.0 already resolves to 6.2.0 on fresh installs; the raised floor is
for upgraders whose lockfile pins rxfire 6.1.0, which survives an
@angular/fire upgrade and recreates the dual-SDK tree. ^6.2.0 forces
the bump.

Also drop the root overrides block that forced rxfire's firebase peer
to ^12.4.0 in this repo's own tree (obsolete with 6.2.0), and sync the
lockfile's stale root version 21.0.0-next.0 to 21.0.0-rc.0 to match
package.json.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant