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!