I think if we combine the two methods the docs will be more readable.

export function getFirestore(app?: App, databaseId: string): Firestore;

I think inviting customers to pass null as a parameter is a bad idea.

The problem is in doc generation that doesn't include parameters in signature:

What I meant to say was to keep both as optional parameters so you don't need three method signatures. It also simplifies the docs.

export function getFirestore(app?: App, databaseId?: string): Firestore;

export function getFirestore(
  appOrDatabaseId?: App | string,
  optionalDatabaseId?: string
): Firestore {

I still think calling getFirestore(null, 'myDB') is worse than having overload getFirestore('myDB').

TypeScript doesn't expose the last signature, nor would I want to. The signature suggests someone could write code getFirestore('myDB', 'myDB') which isn't allowed.

export function getFirestore(
  appOrDatabaseId?: App | string,
  optionalDatabaseId?: string
): Firestore

Would it make more sense to include the databaseId in FirestoreSettings?

TLDR; No, I I think this is a bad idea.

The admin SDK manages lifecycle of Firestore instances, such that subsequent requests will return the same instance. The app and databaseId form the key to this cache, and should really be held separate from settings in my opinion.

Other methods such as getFirestore, do not take a settings object. Adding a settings object here would conflict with intent to have getFirestore simply be a method to return an existing instance (if one exists).

initializeFirestore cannot be called with different settings, since settings cannot be changed after Firestore instance has been started. The semantic difference that "some" settings such as database id are allowed to change, will simply add confusion to interface. A simple rule that no settings are allowed to change can be maintained by excluding databaseId from settings.

Makes sense! Thank you

Please get these documentation changes reviewed by a tech writer before merging the PR. Thanks!

@markarndt

Thanks Mark!