Update dependencies for SDK 46
SimenB opened this issue ยท 10 comments
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'sexpo.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 theexpo
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"
},
}