Unable to perform Facebook login after updating to Expo Go 2.25.1

I also get this Failed to resolve plugin for module "react-native-fbsdk-next" relative to {path here} expo-config(PLUGIN_NOT_FOUND) inside my app.json file… so this tells me I do need that app.config.js or I need to prebuild? :thinking:

I see what you mean, but I think most of the time after you are able to build the dev client, you can then just use that to iterate on the JS code. The main issue is getting the dev client built the first time.

No. The terminology is a bit more complicated because of the greater power and flexibility of current versions of Expo.

Basically, a bare workflow app means you now have ios and android native projects that you need to edit if you want to do something like change the app name, or the icon or the splash screen or install certain native dependencies etc.

eas build works for managed apps and bare apps. Just running eas build does not turn your managed app into a bare app.

However, if you run npx expo prebuild or npx expo run:ios, then the native ios and android projects will be generated. At this point you basically have a “bare” app, but you can revert to a managed app by reverting the changes done by npx expo prebuild.

There’s also something that’s sort of between managed and bare.

  • With managed, you never have ios and android directories (or if you run npx expo prebuild, you clean them up afterwards.)
  • With bare, you pretty much ignore app.json and have to make manual changes in the native projects, and upgrading to later versions of React Native is harder.
  • The “in between” option is to use npx expo prebuild --clean to regenerate your native ios and android projects. You might do this after changing something in app.json or installing a native dependency that has a config plugin. (If you have made any changes to the native projects that you want to keep, you’d need to re-apply those changes yourself.)

Added to the above, “managed” is also kind of split in (at least) two things these days.

  • You only use the Expo SDK? Then you can use Expo Go and the classic build system (until the classic build system is shut down.)
  • You need some native dependencies not included in the Expo SDK? Then you need to build a dev client and use EAS Build.

So as long as you do not have ios or android directories, building with EAS Build is still the managed workflow as far as I’m concerned.

You should not have to worry about the bare sections of the docs if you’re just building a dev client.

hmmm… the Expo team has said something recently about switching to a project ID instead of the account/slug that they used in the past. As long as you use app.json instead of app.config.js then I think the eas build command should add it automatically. If you use app.config.js it should tell you what you need to add.

Maybe see if the troubleshooting page helps:

I understand. As I said, it’s got more complicated as it got more powerful.

Actually yes. Although the following refers to the Bare workflow it should work just as well for a “managed” app that you have installed a native dependency in:

Where do you get that? Is that in VS Code?

What do you have in the "plugins" section of your app.json? And does it build if you run eas build --profile development --platform ios?

No, it should work fine with app.json and you should not need to prebuild.

I hope this post clarifies more than it confuses :sweat_smile:

Haha yes this is very helpful and gives me a better understanding for sure of the current expo landscape and how it as evolved.

As long as I don’t see any ios and android folders in my main project folder I think I am good and not “ejected” or “bare”. I think that works best for me so far. And I think I should be good staying away from prebuild as well, if I can keep it.

And yes, that error shows in VS Code and I am still trying to figure out how to put multiple plugins in the json file, where some plugins don’t have configurations, while others do… Maybe my formatting is wrong…
I don’t use app.config.js now and not even sure how to do that so definitely just want to stay with app.json if possible.
Does this seem correct?

"plugins": [      
      [
        "react-native-fbsdk-next",
        {
          "appID": "***************",
          "clientToken": "***************",
          "displayName": "***************",
          "advertiserIDCollectionEnabled": false,
          "autoLogAppEventsEnabled": false,
          "isAutoInitEnabled": true,
          "iosUserTrackingPermission": "This identifier is not used with this application."
        }
      ],
      "sentry-expo"
    ]

Or this is more correct?

"plugins": [      
      [
        "react-native-fbsdk-next",
        {
          "appID": "***************",
          "clientToken": "***************",
          "displayName": "***************",
          "advertiserIDCollectionEnabled": false,
          "autoLogAppEventsEnabled": false,
          "isAutoInitEnabled": true,
          "iosUserTrackingPermission": "This identifier is not used with this application."
        }
      ],
      ["sentry-expo", {}]
    ]

And btw what you see in the screenshot seems to build fine with eas build --profile development --platform ios, but I have yet to try it to see if that plugin actually works…

Also I noticed that the Constants.executionEnvironment value is now bare when I debug the app in the custom dev client… That is what is making me a bit confused again :thinking:

I think that makes the most sense.

OK, I don’t use VS Code. I’m not sure if that warning is valid. Since it builds for you it seems maybe the warning is spurious :thinking:

One other possibility (although it seems unlikely) is that there is a react-native-fbsdk-next dependency listed in package.json, but it’s not actually installed (in node_modules/react-native-fbsdk-next) for some reason.

e.g. this could happen if you had this project checked out on two separate machine and you installed the package on one machine and pushed to GitHub. Then on your current machine you ran git pull to fetch the package.json and yarn.lock/package-lock.json changes from GitHub, but did not run yarn or npm install after that to update node_modules. If something like this is the case then the VS Code plugin would not be able to find react-native-fbsdk-next in node_modules on your machine, but when you run eas build, the build server would install the package as per package.json and yarn.lock or package-lock.json, so the react-native-fbsdk-next stuff would be in node_modules on the build server.

Maybe also just make sure you have the latest version of the VS Code plugin installed :man_shrugging:

The first one looks fine to me. The second one should also work, though.

Basically, each entry in the "plugins" array should be either a string or a two-element array. (If I remember correctly it could also be a function if you were using app.config.js, but since you’re using app.json it can only be a string or a two-element array.)

If you use a string to refer to the plugin, then there are no extra parameters/config for that plugin.

If you use a two-element array to refer to the plugin, then the first element must be a string (or again with app.config.js it could probably be a function), and the second element is some kind of config for the plugin. This could be a single value or another array or (as in the case of react-native-fbsdk-next) it could be an object.

So in your case you have two elements in the "plugins" array.

  • [“react-native-fbsdk-next”, {…}]
  • “sentry-expo”

i.e. a two-element array and a string. Looks good to me.

hmmm… I haven’t checked Constants.executionEnvironment before, so not sure what’s going on there. I would not expect that to be bare, but maybe I’m missing something.

Okay yes thank you for the plugins info / clarification. Didn’t know it can accept that type of format and it does seem to work the way I had it. Still not sure why VS Code complains. This project is not committed to github and is brand new and only local to one machine so far. Also don’t have react-native-fbsdk-next dependency listed anywhere else by any other package :man_shrugging:

Will not worry about the Constants.executionEnvironment just yet. Seemed odd though.

And somewhat off-track, but noticing that only on android and only on custom dev build, one package is acting up differently. the firebase js package "firebase": "8.2.3" is always unable to connect from a couple different android devices I’ve used. the exact same build works fine on iOS (Expo Go and custom dev) and Android Expo Go. but not in the Android custom dev build… Very odd behavior. it just yields this error @firebase/firestore: Firestore (8.2.2): Could not reach Cloud Firestore backend. Backend didn't respond within 10 seconds. and followed by lots of @firebase/firestore: Firestore (8.2.2): Connection WebChannel transport errored I guess from it trying to reconnect… :thinking: puzzled