jakobo/expo-community-flipper

Update dependencies for SDK 46

SimenB opened this issue ยท 10 comments

"@expo/config-plugins": "^4.0.15",
should be v5

Thanks @SimenB. I can carve out some time today (thanks expo team for quick answers in discord) to put a PR together. We haven't moved to 46 yet, so I'll need to update the example/ app as well. Building a quick todo list to test the changes.

Local test:

  • Checkout, change, and build
  • Copy ./plugin/build/withFlipper.js to your local repo, and add it to your app.json's expo.plugins collection
  • Run expo prebuild and verify no errors. include podfile and gradle properties file in PR

One concerning thing is I can't find a changelog for the breaking changes introduced with config-plugins v5.

https://github.com/expo/expo/tree/main/packages/%40expo/config-plugins, https://github.com/expo/expo-cli/blob/main/CHANGELOG.md, and https://github.com/expo/expo/blob/main/CHANGELOG.md don't show any changes. I think the v5 change came from the config-plugins repository moving to its new home, but want to confirm.

Pinging @brentvatne who cut the release in 093d340c to make sure

From Kim in the Expo Discord #eas

Valid question. We're in the process of setting up proper changelogs along with the repository move for these packages. To answer your question specifically, this is the only change between v4 and v5: expo/expo-cli@55bd16c

Since that's not a backwards incompatible change, it's likely the v4=>5 came from the repository move. Either way, we don't depend on the plist changes since the plugin uses regex and it should be a straightforward upgrade.

Alright, we should be compatible with SDK 46 now. There were a few more changes because RN 0.68+ uses objective-c++, but there was a config mod we could use without adding any complexity. Do open an issue if you run into any problems

Thanks!

sorry for the thrash on the changelogs from the migration from expo-cli to the expo repo. we talked about this today internally and it should be better in the future.

also - we're moving away from recommending that libraries depend on the @expo/config-plugins package. instead, we will recommend that they have a peer dependency on the expo package and then use peerDependenciesMeta to mark it as optional (if it is, indeed, optional). this should be easier for libraries to keep track of, rather than deciding on a specific config plugin version it can just use the version that is installed by the expo package.

No worries, appreciate the insight!

Given expo-community-flipper tracks against the SDK, the move to a dependency on just expo would be awesome. Do you think it'll land in 47 or 48? I can make a ticket over here in the plugin repo so we don't forget. :)

@jakobo - you can move over to a peer dependency on the expo package now instead if you like!

one question for you - how do you feel about having a peer dep on the expo package but then importing @expo/config-plugins in your plugin code? i'm thinking about whether we should be re-exporting @expo/config-plugins from the expo package so it's more explicit

From a maintainer perspective, having a single non-optional peer dependency makes things easier when we track against the SDK itself. I also think we're kinda unique; we tie in to Flipper, which comes with a specific react-native version, which is pinned to the Expo SDK version.

My biggest fear would be that updates to the config plugin architecture & functions would also be tied to the mainline, but that's avoidable as long as you can still depend on @expo/config-plugins as an escape hatch if the packages update between major releases.

i'm thinking about whether we should be re-exporting @expo/config-plugins from the expo package so it's more explicit

I know you didn't ask me (๐Ÿ˜€), but anything other than explicit dependencies (peer or otherwise) relies on implementation details in hoisting and have no guarantees from package managers to actually work. And it won't work at all for yarn pnp or pnpm. So re-exporting from a dependency seems like the obvious choice ๐Ÿ™‚

I know you didn't ask me (๐Ÿ˜€)

Anyone with pnpm and pnp experience is greatly appreciated โค๏ธ If pnpm is really good about enforcing peer dependencies, then it makes this plugin much easier to manage; this package's deps reduces down to:

{
  "devDependencies": {
    "@expo/config-types": "^46.0.1",
    "expo": "^46.0.0"
    "expo-module-scripts": "^2.0.0",
    "tslint": "^6.1.3",
    "typescript": "^4.5.2"
  },
  "peerDependencies": {
    "expo": "^46.0.0"
  },
}