Using on Expo project

[simoneb]

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.

[rarkins]

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).

[karlhorky]

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-storage

It'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.

https://github.com/upleveled/hotline-bling-codealong/blob/main/.github/workflows/cron-expo-install-new-versions.yml

[soullivaneuh]

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?

[soullivaneuh]

By the way, we already have a somewhat related expo monorepo group preset configured here:

renovate/lib/config/presets/internal/monorepo.ts

Line 89 in 25c60af

expo: 'https://github.com/expo/expo',

However, it was not very helpful to me because of this discussion subject, and I am not currently using it.

[github-actions[bot]]

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

[jmatsushita]

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:

https://github.com/expo/expo/blob/8010f0ca72ba25eb19e304002df40a68ace93fa4/packages/expo/bundledNativeModules.json#L98

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"
    }

[lucaslosi]

i'm on a monorepo and to "fix" this issue blocking renovate + expo, i've setup extra steps on my pull request action that runs if expo-doctor fails:

• runs npx expo install --fix to fix deps that doesn't met the expo-doctor requirements
• runs syncpack to sync the deps on my monorepo
• fix yarn.lock for the new deps
• commit the changes
• runs expo-doctor again to check if it passes

you should set "preferVersion": "lowestSemver" on .syncpackrc if you want to hold lower versions that come from expo install --fix or 'expo.install.exclude' if you want to keep the upgrades and ignore them on expo checks