chore: Allow type-safety for subcollections

[fivecar]

Description

Root collections currently allow strong typing:

const allYourBase = firestore()
  .collection<SetUsUp>("are-belong")
  .get();

But subcollections cannot be typed:

const allYourBase = firestore()
  .collection<SetUsUp>("are-belong")
  .doc("8675309")
  .collection<TheBomb>("to-us")  // This is not accepted by index.d.ts
  .get();

This PR attempts to make that possible.

Release Summary

Support strong typing for subcollections

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • Yes
• My change supports the following platforms;
  • Android
  • iOS
  • Other (macOS, web)
• My change includes tests;
  • e2e tests added or updated in packages/\*\*/e2e
  • jest tests added or updated in packages/\*\*/__tests__
• I have updated TypeScript types that are affected by my change.
• This is a breaking change;
  • Yes
  • No

Test Plan

Installed local version in my project, and verified that Typescript accepts a subcollection type.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-native-firebase	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 26, 2025 10:23pm

[github-actions]

Hello 👋, this PR has been opened for more than 2 months with no activity on it.

If you think this is a mistake please comment and ping a maintainer to get this merged ASAP! Thanks for contributing!

You have 15 days until this gets closed automatically

[fivecar]

@mikehardy @MichaelVerdon Would you mind taking a look, or passing to the right folks? (Apologies, wasn't sure who's best to look, but both of you seem quite active in this project)

[mikehardy]

Hey @fivecar - sorry for the delay - thanks for posting this. A couple questions

1- what's the backwards-compatibility status for this, how it will it affect use of DocumentReference in existing code? Will everyone get type errors now if they are not specifying the second type? If so, is it possible to make that second type optional?
2- I looked and I think the answer is yes but - how does this affect use of DocumentReference in the modular API? If you are using this patch locally (at least while testing it...) how does it affect your code when you migrate it to the modular API ?

Thanks!

[fivecar]

@mikehardy Thanks for the thoughtful response!

What about existing code?

I believe existing DocumentReference code won't be affected because nobody, prior to this change, could pass a type to DocumentReference.collection() (i.e. no existing code can firestore().collection("boris").doc("yeltsin").collection<Stuff>("stuff"), prior to this PR). So with this PR, all that existing code continues to be implicitly typed DocumentData when chaining collection() calls.

What about the modular APIs?

I've tested with and without the modular API, and the results are the same with this PR. Using the following code as an example:

  return getFirestore()
    .collection(Collections.SECURE_PROFILE)
    .doc(uid)
    .collection<PersonYouMayKnow>(Collections.PYMK);

the returned type is FirebaseFirestoreTypes.CollectionReference<PersonYouMayKnow>. But if you change the code to:

  return getFirestore()
    .collection(Collections.SECURE_PROFILE)
    .doc(uid)
    .collection(Collections.PYMK); // OG style, the only style allowable before this PR

the returned type is FirebaseFirestoreTypes.CollectionReference<FirebaseFirestoreTypes.DocumentData> (i.e. exactly what it was prior to this PR).

LMK if that all makes sense.

[mikehardy]

That does make sense - seems like this should work, thanks for your replies