RFC: v1 roadmap

[kmjennison]

next-firebase-auth has been reasonably stable for a while now and is already used in production apps, so it feels an appropriate time to move toward a v1 release.

This is an in-progress document of the changes that might land in v1. Please comment with any feedback or questions.

The unstable releases are available as next-firebase-auth@canary. When contributing, please make pull requests to the v1.x branch.

Demo: the demo app is deployed here.

---

Prerequisites

• [x] Set up a canary/next/v1 branch and release process (@kmjennison)
• [x] Set up a canary live demo (@kmjennison)

Making the package work better

• [x] #164
  • Drop support for Firebase <9
• [x] #174
• [x] Fix bug with HMR: #163
  • Potentially via #207
• [x] #142
• [x] #488

Making the package more flexible

• [x] ~#190~ Deferred: we'll delay this to a potential later release because 1) we won't want to complicate adoption of Firebase v9, 2) we haven't identified a suitable cookies library, and 3) this library might have a cookie-free future (see #287).
  • [x] Identify a suitable cookies library
  • [x] Identify a clear migration strategy for existing apps to avoid cookie mismatches
  • [x] Implement
  • [x] Write migration documents
• [x] #223
• [x] #233
• [x] #444

Preventing incorrect use

• [x] #155
• [x] #195

Developer tools

• [x] #389

Cleanup

• [ ] Make API name changes
  • Instances of AuthUser: AuthUser --> user
  • withAuthUser --> withUser
  • withAuthUserTokenSSR --> withUserTokenSSR
  • withAuthUserSSR --> withUserSSR
  • useAuthUser --> useUser

Before release

• [x] #296
• [ ] If needed, provide a codemod (jscodeshift)
• [ ] Write migration guide
• [ ] Ensure README is up to date

[HofmannZ]

Hi, I'm picking up Firebase v9 support 👨‍💻

[atanaskanchev]

@kmjennison @HofmannZ Hi, any updates on the v1 release?

[kmjennison]

@atanaskanchev This is our checklist for a v1 release. I welcome contributions to speed things along. Meanwhile, v1 changes are available on the canary release channel.

[kmjennison]

We might defer a unified cookie feature (#190) to a later release because:

1. we won't want to complicate adoption of Firebase v9
2. we haven't identified a suitable cookies library, and
3. this library might have a cookie-free future (see #287)

[VewMet]

When will this library be available for next 12 version ?

[kmjennison]

@VewMet Next 12 is supported in the latest releases.

[PatrikTheDev]

Firebase-admin 10.0.0 support should also be added to the roadmap

[kmjennison]

@Patrik-svobodik Firebase admin v10 is already supported.

[seanaguinaga]

Is Next.js' middleware functionality a place that next-firebase-auth could live? I assume it would be more performant? But does that make the hybrid server and client approach currently used almost impossible?

https://nextjs.org/docs/middleware

That could mean that pages lose auth/redirect on a page by page basis, instead be determined by file placement.

[kmjennison]

@seanaguinaga Thanks for flagging this. I opened an issue for middleware discussion here: #418

[DiegoGonzalezCruz]

Hi guys, hope everything is going great. I am wondering if you have an estimated ETA for v1?

[kmjennison]

@DiegoGonzalezCruz We don't have an ETA—we're making progress as we have time. We welcome contributions on open issues. Meanwhile, next-firebase-auth@canary is available to use.

[jodik]

Hi,

it seems admin side is also modular: import { initializeApp } from 'firebase-admin/app';

Currently we do: import * as admin from 'firebase-admin' admin.initializeApp()

[raajnadar]

@kmjennison is that safe to use next-firebase-auth@canary for a production app or the canary is for testing?

[kmjennison]

@raajnadar Yes, the canary releases are intended to be fully functional and usable in production. However, they'll be less stable and less tested than major releases, so you should only use it if you have tolerance for possible bugs or breaking changes.

The current canary version will see more breaking changes before it hits v1 stable. See release notes for these changes.

[seanaguinaga]

@kmjennison I am having a hard time upgrading to v17 - the admin config for initAuth is different?

have a complete example?

[kmjennison]

@seanaguinaga The config hasn't changed, but there are some breaking changes in v1.0.0-canary.17 (see release notes). Notably, we dropped support for firebase-admin v9 and removed the getFirebaseAdmin method. Instead, if you need the Firebase admin app, import it directly.

[louisgv]

@kmjennison I tried canary.17 and am receiving this error:

Error: The default Firebase app does not exist. Make sure you call initializeApp() before using any of the Firebase services.

canary.16 worked. With canary17, I removed the getFirebaseAdmin and replaced them with getFirestore() directly. I also ran initAuth() before these API route, even placed the initAuth right before the getFirestore() like this:

initAuth()
const firestore = getFirestore()

And the error still throw

[louisgv]

More context: I'm invoking these inside a getServerSideProps()

[louisgv]

Fixed it by wrapping the getServerSideProps inside the withAuthUser

EDIT: Apparently it worked locally, but when deploy it throws the error on the function...

[strid408]

I'm also having issues with the 'app/no-app' error code when trying to access the admin sdk on the server side. Both in API routes and getserversideprops. Strangely enough, it seems to work sometimes. I got it working suddenly, restarted the app, and then the errors came back..

[kmjennison]

If you're running into a bug, please try the example app with your own Firebase credentials (if you haven't already) to see if the bug exists there. Then, please open an issue with a minimal example app and instructions to reproduce.

[kmjennison]

v1 beta is out! 🎉 Check out the migration guide and let me know if you run into any issues.

[kmjennison]

v1.0.0 has been released!