Using on Expo project
simoneb opened this issue · comments
Which Renovate are you using?
WhiteSource Renovate App
Which platform are you using?
GitHub.com
What would you like to do?
Renovate doesn't seem to work so well with attempting updates on expo based projects. Is there a way to perhaps ask renovate to run a different command? For instance, expo based projects wrap npm and add some guard rails, so what you use is expo install and expo update instead of the npm counterparts.
I think we would need to treat this like a feature request in the main repo so have transferred it. It sounds a little like #3681 (RushJS support) in that you want to use a specialized CLI command instead of npm. It's getting challenging to detect all these variants (including Lerna too) and automatically do the right thing (e.g. without requiring users to explicitly configure Expo or Rush or Lerna or disable npm).
It sounds a little like #3681 (RushJS support) in that you want to use a specialized CLI command instead of
npm
Right, here in this case it's to use the expo install command instead of npm install / yarn add:
- npm install @react-native-async-storage/async-storage
+ expo install @react-native-async-storage/async-storageIt's getting challenging to detect all these variants (including Lerna too) and automatically do the right thing
Yeah, I can imagine, keeping up with all the different variants of tooling and where the config lives must be difficult.
In case Renovate still wants to give autodetection a shot, maybe a starting heuristic could be app.json with a "expo" key - which most Expo apps have, such as seen in this managed Expo app:
https://github.com/upleveled/hotline-bling-codealong
Workaround
I've created a GitHub Actions workflow that creates pull requests weekly based on running expo update (example PR). Not as nice as Renovate bot, but it works.
It's getting challenging to detect all these variants (including Lerna too) and automatically do the right thing
@rarkins Why not starting with that ruleset?
{
"packageRules": [
{
"matchSourceUrlPrefixes": ["https://github.com/expo"],
}
]
}This is not an exhaustive match, but we can at least be sure that package coming from expo itself must be updated using expo install instead of npm install.
For the rest as the other package has to be installed with expo install only if we are using expo, this matching will indeed be harder.
However, we may maintain a package list for that on a :expoProject preset to be manually activated.
Is that making any sense?
By the way, we already have a somewhat related expo monorepo group preset configured here:
However, it was not very helpful to me because of this discussion subject, and I am not currently using it.
Hi there,
Get your issue fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.
Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this.
To get started, please read our guide on creating a minimal reproduction.
We may close the issue if you, or someone else, haven't created a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.
Good luck,
The Renovate team
e.g. without requiring users to explicitly configure Expo or Rush or Lerna or disable npm
Explicit configuration of the CLI command would be a fantastic start!
Another important aspect of an expo project, is that a given expo version pins a number of versions of other react-native libraries which don't belong to the expo monorepo.
For instance if I run expo install react-native-webview today (with expo@48.0.19), although the latest published version on npm is 12.4.0, I will get react-native-webview@11.26.0 the mapping is here (this is the master branch though, so it's best to refer to the published code on npm:
However, renovate doesn't consider this currently, so I have to customise the renovate.json to pin these versions.
This might also be an application of #19645
Here's the relevant part of my renovate.json (grouping isn't necessary, but it's nice for readability):
{
"matchPackageNames": ["@expo/vector-icons"],
"allowedVersions": "^13.0.0",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["expo-crypto"],
"allowedVersions": "~12.2.1",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["expo-dev-client"],
"allowedVersions": "~2.2.1",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["expo-font"],
"allowedVersions": "~11.1.1",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["expo-sensors"],
"allowedVersions": "~12.1.1",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["expo-splash-screen"],
"allowedVersions": "~0.18.2",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["expo-status-bar"],
"allowedVersions": "~1.4.4",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["react-native"],
"allowedVersions": "0.71.8",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["react-native-web"],
"allowedVersions": "~0.18.10",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["react-native-webview"],
"allowedVersions": "11.26.0",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["react-native-reanimated"],
"allowedVersions": "~2.14.4",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["react-native-safe-area-context"],
"allowedVersions": "4.5.0",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["react-native-screens"],
"allowedVersions": "3.20.0",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["sentry-expo"],
"allowedVersions": "~6.1.0",
"groupName": "expo-48-0-19"
},
{
"matchPackageNames": ["@sentry/react-native"],
"allowedVersions": "4.13.0",
"groupName": "expo-48-0-19"
}