Support Modular Firebase 9

[litewarp]

Is your feature request related to a problem? Please describe.
Firebase bundle size is huge. Version 9 introduces a new import strategy that significantly reduces bundle size.

Describe the solution you'd like and how you'd implement it
Ideally a beta or "@next" version of the package that opts into the 'modular' (and not the 'compat' bridge) version 9 loading strategy.

Is this a breaking change?
Would this require existing users to change how they're using next-firebase-auth?

Likely. Functions are now modular which means you need to pass the app instance into the function.

[kmjennison]

It looks like the upgrade path would be:

• Drop support for Firebase JS SDK <v8 to start using compat mode
• Drop support for Firebase JS SDK <v9 to use exclusively modular mode

[litewarp]

So yeah, if you choose to have an incremental upgrade path, you could do two stages, compat and then the modular. Here's why I think you should skip the compat phase:

1. You've said previously that this is an auth only library. The firebase upgrade path explicitly states that the use case for skipping the compat path is for people who just want the auth function alone:

For apps with a very small exposure to the Firebase Web SDK – for example, an app that makes only a simple call to the Authentication APIs – it may be practical to refactor version 8 code without using the version 9 compat libraries.

2. There's little to no benefit in bundle size with the compat libraries. Once again from the firebase docs:

compat libraries have little to no size or performance advantages over their version 8 counterparts.

3. Any breaking changes or migration effects can be mitigated with a @next version published on npm, i.e. let advanced users opt-in to firebase 9.

• Pros: Adopt firebase 9 early; increase adoption of the package by eliminating a serious concern (bundle size); identifies potential migration issues ahead of time for users who don't want to opt-in; be cutting edge and cool.

• Cons: Potentially two code bases to maintain; unintended side-effects.

I'm obviously in favor of the @next branch, at least for the firebase 9 upgrade path. It's something you will have to do at some point anyways.

[kmjennison]

@litewarp I appreciate your thoughts and agree with the @next approach. The diff should be pretty limited, so I think it'll be reasonably easy to maintain.

As a note on a limitation, because we use FirebaseUI for the demo app:

Modular v9 is not currently compatible with FirebaseUI for Web.

[litewarp]

Ahh, nuts. Not having FirebaseUI is a pain. That would definitely be a roadblock to adoption. Once again, we are at the mercy of the Googleplex. I'll start hacking away on it at some point, but guess there's not really a rush now.

[kmjennison]

@litewarp Still good to move forward with this. Not sure how many developers rely on FirebaseUI, plus I'd guess Firebase will add support as v9 moves out of beta.

[litewarp]

So this may be trickier than I anticipated. In the new modular scheme, there's no guard against a redundant initialization -- i.e., there's no firebase.apps.length to check against. The best we can do is call the getApp() function. (See here) and see if it errs (which it does if no app instance is found).

However, even guarding for that with a try/catch initialization block, there's still some sort of race condition where firebase isn't initialized before the app tries to render which causes the getConfig() function to throw.

I'm going to create a new app from scratch soon and see if I can get firebase 9 working before adding in next-firebase-auth, and go from there, but I thought I'd post here as an update and as a request for anyone who might have tried firebase 9 already to offer more insight.

[flaming-codes]

@litewarp You're right that firebase.apps.length isn't a thing in v9+, but their functional equivalents are provided. This is just a simple snippet I'm using in a greenfield Next.js-project with Firebase 9.0.0-beta.2 (the project itself is just for exploring Next + Firebase):

import { initializeApp, getApps } from "firebase/app";
import config from "./config";

export const fire = getApps().length === 0 ? initializeApp(config) : getApps()[0];

[litewarp]

I actually figured that part out and got it working BUT there was no way to use firebaseui or the compat library without having to initialize a second app instance using the compat library which caused all sorts of problems ... so I put it off for a bit. Also my current project is using MS auth, so haven't had much time in firebase land lately.

Will try and share what I've done so far this weekend so others can pick it up if they have time.

[gavinharris-dev]

FYI: Firebase UI support is being worked on in this PR: firebase/firebaseui-web#850

[lightsound]

Firebase v9 is now GA! 🎉
https://firebase.googleblog.com/2021/08/the-new-firebase-js-sdk-now-ga.html

[kmjennison]

Closed in #291 and available on v1 @canary.