Surprising FirebaseError: "Please be sure to call initializeAuth or getAuth before starting any other Firebase SDK."

[akauppi]

I got this in browser:

FirebaseError: ... Another Firebase SDK was initialized and is trying to use Auth before Auth is initialized. Please be sure to call initializeAuth or getAuth before starting any other Firebase SDK. (auth/dependent-sdk-initialized-before-auth).

The culprit was this line:

const [firestore, fns, auth] = [getFirestore(app), getFunctions(app), getAuth(app)];

By reordering the line I can make the error go away:

const [auth, firestore, fns] = [getAuth(app), getFirestore(app), getFunctions(app)];

I'd like to open a discussion about this. In my opinion,

a) the error message is misleading - there are not necessarily more than one Firebase app SDK involved.

b) Is it really necessary, code-wise, to need to have getAuth before the others?

If this really, really, is the case, and presuming every app in the universe needs the auth handle for something, how about returning it already from initializeApp? Having getAuth makes sense if it is conceptually on the same level with the other get... functions.

The new modular API states making things explicit as one of the design goals. Here, there are clearly some implicit underpinnings with the module system (other modules implicitly dependencing on auth). Can these be made explicit?

Firebase 0.900.15

[Feiyang1]

a) the error message is misleading - there are not necessarily more than one Firebase app involved.

I think you might have misread the message. it's actually initializeAuth() not initializeApp().

b) Is it really necessary, code-wise, to need to have getAuth before the others?

Yes, and you are correct that some modules implicitly depends on Auth. For example, Firestore/Storage/Database.

The order of initialization doesn't matter in the old SDK because Firestore/Storage/Database is able to initialize auth automatically on your behalf. And it will always work because the old Auth SDK is monolithic and support all use cases (rn, cordova, all persistence implementations, all redirect resolver implementations, etc). It's also why it's so big

In the new Auth SDK, we allow developers to pick which persistence implementations (and their fallback order) and redirect resolver implementations to use using initializeAuth(). This allows you to reduce bundle size by not including things you don't need. getAuth() calls initializeAuth() under the hood and pulls in platform-specific defaults.

As a result, Firestore/Storage/Database can't automatically initialize auth on your behalf anymore because they don't know what dependencies you want to use with Auth, otherwise we loose all treeshaking benefits.

The alternative, as you mentioned, is to let developers pass an auth object to Firestore/Storage/Database explicitly. Something like:

const auth = initializeAuth(firebaseApp, { persistence: indexedDBLocalPersistence });
const firestore = initializeFirestore(app, auth, settings);

We didn't choose it because we think it offers a worse dev experience

• If you forgot to pass the Auth object when initializing Firestore/Storage/Database, they will work without Auth, which is probably not what you want. And since you don't get any error, it's harder for you to find the problem.
• This makes migration more complicated because it's a different pattern than the old SDK, and a lot of people are likely going to be tripped by it. (this can be somewhat mitigated by a migration guide, but is not ideal)
• If you uses multiple products that work with Auth (e.g. Firestore and Storage), you will need to pass an auth object to all of them, and make sure it's the same auth object, otherwise you will run into weird inconsistency issues.

[Feiyang1]

Interesting idea. Just that I understand you correctly, you are suggesting to allow people to create a customized auth in addition to the default auth created by initializeApp(), and people can pass this customized auth to Firestore/Storage/Database explicitly, otherwise the default auth will be used?

What happens if developer pass the customized auth to Firestore and Storage, but not Database? Will Database use the default auth, but Firestore/Storage uses the customized one? This is something we want to avoid as there will be 2 different Auth states per app, which can be very confusing.

Also what auth dependencies (persistence implementation and redirect resolver) do we use to create the default auth? Keep in mind that we won't be able to treeshake anything we provide by default.

[akauppi]

You got my suggestion right. Now, all the responsibility is on you guys, of course. I am not even the right person to answer the issues you are bringing up. I’m using the default auth only, but so are maybe 90% of the Firebase JS users (do you have statistics?) I have no practical knowledge of persistence implementation or redirect revolver; haven’t needed such, yet.

I think a good design ”just works” for the simple cases and is explorable when one needs more complexity.

[akauppi]

About the error message.

It seems for Firebase authors an ”SDK” means the Database SDK, the Auth SDK and so forth..

This is likely not so for developers. We do ”npm install firebase@exp” and at least for me - that’s the one SDK. The error message really had me thinking there are two separate Firebase SDK instances in my setup (possible; the other could creep up via dependencies).

So this highlights a conceptual difference between the creators and the users. This is exactly why this Discussions area was started, I think, to get this kind of misalignments ironed out.

[Feiyang1]

I think a good design ”just works” for the simple cases and is explorable when one needs more complexity.

This is our goal as well. I will bring it back to the team to discuss how we can improve this API. Thank you for the feedback!

It seems for Firebase authors an ”SDK” means the Database SDK, the Auth SDK and so forth..

Correct. SDK refers to @firebase/database, @firebase/firestore, etc. But I agree the message is confusing since we recommend people to use firebase package, where each product is just a submodule. We will update the message to eliminate this confusion.

[Feiyang1]

This has been addressed in our beta release. You are no longer required to call getAuth or initializeAuth first.