[🐛] ISSUE Expo SDK 48 relies on @expo/config-plugins v6+ and RNB/app and RNB/auth needs v5.4.

[moxen-dev]

Issue

Describe your issue here

Hi folks, this could be a minor issue but since I noticed I decided to share with you. I am upgrading my app to the just released expo SDK 48 and during the examination of conflicts, I found that 2 libraries here still need an older version of an expo library.

@expo/config-plugins@5.0.4
node_modules/@react-native-firebase/app/node_modules/@expo/config-plugins
  @expo/config-plugins@"^5.0.4" from @react-native-firebase/app@17.3.1
  node_modules/@react-native-firebase/app
    @react-native-firebase/app@"^17.3.1" from the root project

@expo/config-plugins@5.0.4
node_modules/@react-native-firebase/auth/node_modules/@expo/config-plugins
  @expo/config-plugins@"^5.0.4" from @react-native-firebase/auth@17.3.1
  node_modules/@react-native-firebase/auth
    @react-native-firebase/auth@"^17.3.1" from the root project

What is annoying is that following the expo instructions to upgrade the SDK, they recommend to do a npx expo-doctor which retrieve the following troublesome message.

It is hard to tell to me if this could really be a problem like introducing any inconsistency, but it will be nice if someone could update this library version on both of these places.

---

Project Files

Javascript

Click To Expand

package.json:

# N/A

firebase.json for react-native-firebase v6:

# N/A

iOS

Click To Expand

ios/Podfile:

• I'm not using Pods
• I'm using Pods and my Podfile looks like:

# N/A

AppDelegate.m:

// N/A

---

Android

Click To Expand

Have you converted to AndroidX?

• my application is an AndroidX application?
• I am using android/gradle.settings jetifier=true for Android compatibility?
• I am using the NPM package jetifier for react-native compatibility?

android/build.gradle:

// N/A

android/app/build.gradle:

// N/A

android/settings.gradle:

// N/A

MainApplication.java:

// N/A

AndroidManifest.xml:

<!-- N/A -->

---

Environment

Click To Expand

react-native info output:

 OUTPUT GOES HERE

• Platform that you're experiencing the issue on:
  • iOS
  • Android
  • iOS but have not tested behavior on Android
  • Android but have not tested behavior on iOS
  • Both
• react-native-firebase version you're using that has this issue:
  • e.g. 5.4.3
• Firebase module(s) you're using that has the issue:
  • e.g. Instance ID
• Are you using TypeScript?
  • Y/N & VERSION

---

• 👉 Check out React Native Firebase and Invertase on Twitter for updates on the library.

[mikehardy]

Hey there! Yes, dependabot just opened a PR for us to bump expo/config-plugins to v6, but as I read their changelog I don't see why v5 to v6 is a semver major. If I adopt this, will I be breaking Expo users that are still on Expo SDK 47? I don't use Expo myself so I'm not sure, perhaps you could ask on Expo support channels if libraries that have config plugins moving to v6 will break non-Expo 48 users and report back. I can bump the dependency if it's fine

In the meantime you can use patch-package to update those package.json's to v6 of expo/config-plugins and move forward locally, if that (patch-package) is something Expo allows

[Poheart]

Hey there! Yes, dependabot just opened a PR for us to bump expo/config-plugins to v6, but as I read their changelog I don't see why v5 to v6 is a semver major. If I adopt this, will I be breaking Expo users that are still on Expo SDK 47? I don't use Expo myself so I'm not sure, perhaps you could ask on Expo support channels if libraries that have config plugins moving to v6 will break non-Expo 48 users and report back. I can bump the dependency if it's fine

In the meantime you can use patch-package to update those package.json's to v6 of expo/config-plugins and move forward locally, if that (patch-package) is something Expo allows

hey there, i am having same expo doctor issue as well. for the time being i'm suppressing it with patch package

i think probably it is the chance to re-review the option to adpot Expo's new config plugin dependency approach raised in discussion section by @barthap before: #6679

Thanks!

[mikehardy]

Yes - good find @Poheart ! I'd be open to a PR that either converted it to peerDependency (perhaps that is sufficient? It might be sufficient?) or switched to the new style (and increased node_modules for devs, but 🤷 )

This would be a breaking change for Expo people (it would strictly require Expo 47+) but that seems reasonable, I believe Expo new version adoption tracks pretty quickly with releases since the upgrade process is marketed as less painful

[Poheart]

IMO having peerDependency will be just fine.

Considering this is a high traffic library, i kinda not in favor the idea of having expo as devDependency (the new style you mentioned), bloating the entire node_modules for those who don't use expo

and yes, it puts the restriction of expo >= 47, but given it's been a while since sdk47 release, and for the foreseeable release cycle of expo SDK, it should worth the change.

[wortkotze]

Is it possible to put the ideas to the next release? we are a little bit blocked at the moment ;)

[dereklucas]

For yarn at least (unsure if NPM uses the same format, but probably) I was able to work around the issue by adding the following resolution to my package.json:

  "resolutions": {
    "@expo/config-plugins": "^6.0.1"
  },

[mikehardy]

Open to PRs on this one

[muhammadk1607]

For yarn at least (unsure if NPM uses the same format, but probably) I was able to work around the issue by adding the following resolution to my package.json:

  "resolutions": {
    "@expo/config-plugins": "^6.0.1"
  },

This is a solid workaround (works for pnpm as well) until the issue is resolved by either peerDependency or version bump.

[LuisRodriguezLD]

For those using NPM, use overrides

"overrides": {
  "@expo/config-plugins": "^6.0.1"
},

[tolypash]

Getting the same, however it was complaining for @expo/config-plugins@~6.0.0 so I had to add that to overrides

  "overrides": {
    "@expo/config-plugins": "~6.0.0"
  },

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.