Issue with ejected Expo Project

Hello,
I am trying to use react-native-version with and ejected expo project. The version in the app.json get incremented but not the one in the Android and in the iOS Project.

It seems that the Expo detection will not check if the project is ejected or not, only if the app.json contains an Expo key.

{
  "expo": {
    "name": "BAC",
    "description": "Description of the app",
    "slug": "exposlug",
    "sdkVersion": "32.0.0",
    "platforms": [
      "ios",
      "android"
    ],
    "version": "1.0.1",
    "orientation": "portrait",
    "icon": "./assets/icon.png",
    "updates": {
      "fallbackToCacheTimeout": 0
    },
    "assetBundlePatterns": [
      "**/*"
    ],
    "android": {
      "publishBundlePath": "android/app/src/main/assets/shell-app.bundle",
      "publishManifestPath": "android/app/src/main/assets/shell-app-manifest.json"
    },
    "ios": {
      "publishBundlePath": "ios/onvabosser/Supporting/shell-app.bundle",
      "publishManifestPath": "ios/onvabosser/Supporting/shell-app-manifest.json"
    },
    "isDetached": true,
    "detach": {
      "iosExpoViewUrl": "https://s3.amazonaws.com/exp-exponent-view-code/ios-v2.10.6-sdk32.0.0-e50ee83a-41bd-4965-b067-4c815a3b3fcc.tar.gz",
      "androidExpoViewUrl": "https://s3.amazonaws.com/exp-exponent-view-code/android-v2.10.8-sdk32.0.0-bca0f957-de78-44c8-91ed-f3151372d79d.tar.gz"
    },
    "scheme": "xxxxx"
  }
}

I believe that checking for the Expo key and for the isDetached could be a way to support Expo detached app and increment the version in the native folders.

Thanks

@jeremybdk

@jeremybdk Sorry for not replying earlier, I'm pretty busy atm, also in the middle of moving.

Seems like that could work. Would you like to submit a PR? The check whether the app is an Expo app or plain RN is here:

react-native-version/index.js

Lines 69 to 78 in 89fa937

    
           function isExpoProject(projPath) { 
        
           	try { 
        
           		let module = resolveFrom(projPath, "expo"); 
        
           		let appInfo = require(`${projPath}/app.json`); 
        
           		return !!(module && appInfo.expo); 
        
           	} catch (err) { 
        
           		return false; 
        
           	} 
        
           }

It should be pretty easy to test. Maybe some other tweaks will be required to update both the Expo config and the RN app, when ejected - if that's what we want.

@stovmascript

@stovmascript I did a bit search and I found out there's not a full-proof way to understand if a RN expo project is ejected (or bare flow) or not.

What I think of creating as PR is to have an additional option in CLI to force updating of native files even if expo has been detected. And leave it up to the user to fix his situation.

Or something like --ignore-expo totally.

@killerchip

@killerchip What about removing the expo key from app.json after ejecting? Is it needed for usage with the Expo SDK after ejecting? (Sorry, I don't use Expo.)

@stovmascript

@stovmascript I'm using expo but not an expo expert myself.

My tests showed:

Using expo-cli to initiate an expo-bare workflow, it does create the expo key in app.json. Removing it has not issue. The app run fine.
Using the expo-cli to initial an expo-managed workflow, and then eject, cannot compile my app at all. So I could not tested it at atm.

Anyway, the solution I'm proposing is not obtrusive. It's an opt-in and removes the concern of managing edge cases with expo from your package, and gives this flexibility to user.

But it's your call in the end :-)

@stovmascript

@stovmascript if the Pullrequest could be accepted it would be awesome!
I'm having the same problems with an ejected expo app, not actually updating the version numbers.

@stovmascript

@stovmascript Even if expo is ejected, there are modules that use expo key in app.json. I think it is a good idea to introduce --ignore-expo option.

ex.) expo-updates - npm

Another option would be to include instructions on how to update the Android and iOS build steps to READ the version information from the "app.json" file.

Here's an easy way to do it in Android:

android/app/build.gradle

def appJson = new groovy.json.JsonSlurper().parse(new File("$rootDir/../app.json"))

// ...
    defaultConfig {
        // ...
        versionCode appJson.expo.android.versionCode
        versionName appJson.expo.version

for iOS I found this suggested solution

I'm actually more inclined to do it the other way around and introduce some --expo option for Expo projects. That way, there wouldn't be a need for any "isExpoProject" logic. On the other hand, it would be a breaking change, but I guess it's not that big of a deal for people to add a flag to their setups.

I would absolutely love an --expo option. As of now, I am still using app.json information even though the project is ejected, so simply deleting does not do the trick.
In the meantime I am just bypassing the problem by adding sth. like this in my package.json scripts for example:

"bump:build": "yarn react-native-version -b && mv app.json app--.json && yarn react-native-version -b && mv app--.json app.json"

@cjthompson

for iOS I found this suggested solution

@cjthompson I have tried below for iOS but its not working for me, version and buildNumber doesn't change.

// iOSVersioning.js, placed inside ios folder
/** @format */

const { exec } = require('child_process')

const APP_VERSION = process.env.APP_VERSION
const app = require('../app.json')
const versionName = app.version
const buildNumber = app.ios.buildNumber

if (APP_VERSION === versionName) {
  process.exit()
}

exec(
  `/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString ${versionName}" -c "Set :CFBundleVersion ${buildNumber}" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"`,
  (err, stdout, stderr) => {
    if (err) {
      console.log('Failed to apply the app version.')
      process.exit(1)
    }

    console.log(`Applied app version: ${versionName}, build number: ${buildNumber}`)
  }
)

and changed my Bundle React Native code and images build phase to:

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
AppVersion=$(/usr/libexec/PlistBuddy -c "Print CFBundleShortVersionString" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}")
APP_VERSION="$AppVersion" node ${PROJECT_DIR}/../iOSVersioning.js
export NODE_BINARY=$(which node)
../node_modules/react-native/scripts/react-native-xcode.sh
../node_modules/expo-constants/scripts/get-app-config-ios.sh
../node_modules/expo-updates/scripts/create-manifest-ios.sh

can you share how you configured it for iOS?

Please apply one of these two PR's which would fix the issue:

--ignore-expo cli option by killerchip · Pull Request #150

Adds two CLI options: --is-bare-expo-workflow and --is-self-hosting-bundles by zibs · Pull Request #243

As a workaround, you may convert your app.json to a app.config.js file, which prevents react-native-version from detecting it as a managed Expo project.

As a workaround, you may convert your app.json to a app.config.js file, which prevents react-native-version from detecting it as a managed Expo project.

I just tried this workaround and got it to work. Minor correction for future searchers. You'll want to convert your app.json into an app.config.json file.

Navigation Menu

Repository navigation

Issue with ejected Expo Project #105

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	function isExpoProject(projPath) {
	try {
	let module = resolveFrom(projPath, "expo");
	let appInfo = require(`${projPath}/app.json`);

	return !!(module && appInfo.expo);
	} catch (err) {
	return false;
	}
	}

Issue with ejected Expo Project #105

Description

Activity

stovmascript commented on May 20, 2019

killerchip commented on Oct 6, 2019

stovmascript commented on Oct 7, 2019

killerchip commented on Oct 8, 2019

nexorianus commented on Mar 24, 2020

yaeda commented on Jul 22, 2020

cjthompson commented on Aug 10, 2020

stovmascript commented on Aug 11, 2020

crolly commented on Nov 24, 2020

summerkiflain commented on Mar 8, 2021

agape-apps commented on Aug 7, 2021

IjzerenHein commented on Feb 14, 2022

jarell4 commented on Nov 7, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions