Upgrading to 10.3.0 broke TypeScript detecting `getReactNativePersistence` function for Expo RN

[seanblonien]

Operating System

iOS 16.4

Browser Version

Chrome latest

Firebase SDK Version

10.3.0

Firebase SDK Product:

Auth

Describe your project's tooling

Expo tooling React Native app with Firebase JS SDK
(Expo 49.0.0)
(VSCode 1.81.1)

Describe the problem

I was following 10.3.0's new error message:

 WARN  [2023-08-24T04:43:17.235Z]  @firebase/auth: Auth (10.3.0): 
You are initializing Firebase Auth for React Native without providing
AsyncStorage. Auth state will default to memory persistence and will not
persist between sessions. In order to persist auth state, install the package
"@react-native-async-storage/async-storage" and provide it to
initializeAuth:

import { initializeAuth, getReactNativePersistence } from 'firebase/auth';
import ReactNativeAsyncStorage from '@react-native-async-storage/async-storage';
const auth = initializeAuth(app, {
  persistence: getReactNativePersistence(ReactNativeAsyncStorage)
});

introduced by #7570, and yet somehow it was missed that the getReactNativePersistence function is no longer exported from the firebase/auth entry point as of 10.0.0 according to VSCode (does not seem to pick up the native entry point if that function is exported):

how do I get my editor to detect the new native entry point?
is this new entry point pattern compatible with managed expo projects, or only bare react-native projects?
(running the numbers quickly, expo is just over 1/3 of the react-native community according to NPM downloads)

#7138 seems to blatantly remove those exported functions without re-exporting them, which seems like they literally are just not exposed and virtually "deleted" from the library. or the native detection just isn't working at all for me, so direction on how to get that working would be helpful

Steps and code to reproduce issue

1. upgrade firebase to 10.3.0 in Expo 49.0.0 project
2. try copying the code from above to initialize the auth object
3. notice the error about it not finding that function

[steven-kovacs]

I have been banging my head against the wall for this exact same problem! Anyone have any solutions?

[jbalidiong]

Hi @seanblonien, thanks for bring this to our attention. I was able to replicate the behavior you mentioned. I’ll notify our team about these issues so that they can provide more context and investigate what might be causing this.

[hsubox76]

That's odd, I tested this specifically in a new Expo project (npx create-expo-app) before releasing, specifically, on an iOS simulator. Are you targeting iOS/Android or are you targeting web?

See this comment in a closed issue:
#7425 (comment)

TLDR: getReactNativePersistence hasn't been removed, it seems like you're getting the web bundle, which seems like either a problem with your resolver config (see linked comment above for details), or perhaps you're targeting web?

Here's one way this can happen, if you've customized your Metro config. Link is here: #7115 (comment) and I'll re-paste it for convenience

Just wanted to leave an explanation for anyone else having this issue. This project's metro config added some custom options to resolver but did it by spreading defaultResolver first:

  resolver: {
    ...defaultResolver,
    sourceExts: [...defaultResolver.sourceExts, 'cjs'],
    blacklistRE: exclusionList([/cdk-app\/.*/, /api-app\/.*/]),
  },

Metro's default resolver settings actually look at mainFields ["browser", main"] because Metro is used in non-React Native projects as well and they wanted to keep the defaults more generic. When you create a React Native project with the React Native CLI, the "react-native" field gets add to the beginning of that, but when you put defaultResolver back into the resolver, it overrides that and sets it back to the generic settings. See facebook/metro#807 for an example.

Their solution is just don't spread defaultResolver. Looks like it's not necessary, anything specified in the resolver field will extend defaults I guess, so you don't have to fully fill it out.

Edit: One last thing, if this is the case, you should have been having this problem ever since upgrading from any version of 9 to 10.0.0, that's when the "firebase/auth/react-native" explicit path was removed and replaced with the automatic resolution.

[iM-GeeKy]

@hsubox76 According to the Expo Firebase Docs when upgrading to a version > 9.7.x it looks like they recommend configuring metro. Could that be the cause?

[hsubox76]

So the problem occurs when applying metro config customizations in a way that somehow accidentally sets mainFields back to the default. The example I quoted above does it by spreading defaultResolver. I'm not sure if the example in the Expo docs will do that or not. Is it possible to log or check the value of defaultConfig at the end of that file? See if it includes mainFields, and if it's set to ["browser", "main"] (incorrect) or if it has "react-native" as the first item in the array (correct).

Also if anyone's seeing this error and targeting web with RN (not iOS/Android), let me know.

[iM-GeeKy]

So the problem occurs when applying metro config customizations in a way that somehow accidentally sets mainFields back to the default. The example I quoted above does it by spreading defaultResolver. I'm not sure if the example in the Expo docs will do that or not. Is it possible to log or check the value of defaultConfig at the end of that file? See if it includes mainFields, and if it's set to ["browser", "main"] (incorrect) or if it has "react-native" as the first item in the array (correct).

Also if anyone's seeing this error and targeting web with RN (not iOS/Android), let me know.

resolverMainFields: [ 'react-native', 'browser', 'main' ],

[hsubox76]

I also just tested out the suggested Metro config in the Expo Firebase docs and it seems to work fine, the resolverMainFields are correct. What error are you seeing? Is it the same as in the original post? ("has no exported member getReactNativePersistence")?

[iM-GeeKy]

Yeah, thats correct.

[steven-kovacs]

Same here. I have installed the correct packages but get this.

[hsubox76]

Sorry, I didn't realize this was specifically a VSCode editor issue. Am I correct that this isn't affecting any builds?

So I have narrowed down the problem. There's a specific TypeScript definitions file for the React Native auth bundle, and if you look at the package.json for @firebase/auth, it's specified alongside the RN bundle if you use the Node ESM standard exports field for resolution:

firebase-js-sdk/packages/auth/package.json

Line 22 in b2f6084

"types": "./dist/rn/index.rn.d.ts",

Unfortunately it looks like Metro (by default at least) doesn't use the exports field for module resolution and uses the top level "mainfields". This lets us specify a react-native code bundle here:

firebase-js-sdk/packages/auth/package.json

Line 7 in b2f6084

"react-native": "dist/rn/index.js",

along with "browser", "main", etc, but unfortunately when using this format, you can't specify a custom typings file to go along with each JS bundle, and (as far as I know) you're stuck with providing one universal type definitions file which is expected to match all the bundles (this is actually rewritten to "auth-public.d.ts" at release time btw):

firebase-js-sdk/packages/auth/package.json

Line 143 in b2f6084

"typings": "dist/auth.d.ts",

So basically that typings definition bundle will work for the majority of auth bundles (for web, Node), but won't work for RN as it's missing getReactNativePersistence. You can "fix" it temporarily by copying the path from line 22 to line 143 in your project's node_modules/@firebase/auth/package.json. But let me see if there's a way to configure Metro to look at exports or if there's a way to provide multiple typings files using the mainFields resolution scheme.

Edit: Again, let me know if this affects any builds or anything beyond the editor and warnings.