Adopting new Expo config-plugins dependency

[barthap]

In the Expo SDK 47 release blog post they wrote this:

Starting with SDK 47, we re-export @expo/config-plugins and @expo/config from the expo package and import the libraries with expo/config-plugins and expo/config (notice there is no more leading @ )

If you are a library author, we recommend referring to the updated “Developing a Plugin” guide for more information on how to update your library to this style of imports. This will save you time in the future because you won’t need to update the @expo/config-plugins version for each release anymore, and your library will be immediately compatible with new expo releases (provided that there have been no breaking changes to the config-plugins API, which is relatively stable at this point).

In the linked guide they recommend doing:

{
  "dependencies": {},
  "devDependencies": {
    "expo": "^47.0.0"
  },
  "peerDependencies": {
    "expo": ">=47.0.0"
  },
  "peerDependenciesMeta": {
    "expo": {
      "optional": true
    }
  }
}

---

Here are a few thoughts from me (temporarily I'm not working at Expo):

• Personally, I'm happy that you finally will not have to ship your library with that expo dependency and keep it up to date:
  

  react-native-firebase/packages/app/package.json

  Line 59 in fe9e404

  "@expo/config-plugins": "^5.0.1",

• On the other hand, I don't like bloating dev node_modules by linking the whole expo package as devDependency - I'd still stick to using @expo/config-plugins directly
• This new approach applies only to expo >= 47.0.0 so changing this right now [in theory] could break for people with older Expo SDKs. I'm wondering if adding @expo/config-plugins >= 5.0.1 as peerDependency would do the job 🤔 as every Expo project should have it installed anyway

What do you think about it?

[mikehardy]

• Pulling in all of expo just to get config-plugins seems bloated, yes
• breaking changes just for what I consider "dev infrastructure" seems overdone
• agreed peerDependency is likely sufficient, for reasons you cite (how could they use the config-plugin without Expo? Seems impossible?)