App.json config not respected

Expo SDK
1

Hey all, I’m new to building standalone apps with Expo and have ran into an issue. I believe I’ve configured app.json properly (I bootstrapped via CRNA), but some of the config settings I defined are not being used when I run exp start or exp build:ios.

Here is the error:

[exp] Logs for your project will appear below. Press Ctrl+C to exit.
[exp] Error: Problem validating fields in app.json. See https://docs.expo.io/versions/v23.0.0/guides/configuration.html.
[exp]  • Field: android.package - 'android.package' should be a reverse DNS notation unique name for your app. For example, host.exp.exponent, where exp.host is our domain and Expo is our app..
[exp] Warning: Not using the Expo fork of react-native. See https://docs.expo.io/.
[exp] Warning: 'graphql' peer dependency missing. Run `npm ls` in /Users/hawkins/git/greene-county-alerts/app to see full warning.
[exp] 
[exp] If there is an issue running your project, please run `npm install` in /Users/hawkins/git/greene-county-alerts/app and restart.

▲ app at icon ✖ cat app.json
{
  "expo": {
    "name": "Greene Co. Alerts",
    "version": "1.0.0",
    "slug": "greene-co-alerts",
    "sdkVersion": "23.0.0",
    "androidStatusBar": {
      "backgroundColor": "#E67E22",
      "barStyle": "light-content"
    },
    "primaryColor": "#E67E22",
    "githubUrl": "https://github.com/hawkins/greene-county-alerts",
    "icon": "./assets/icon.png",
    "ios": {
      "bundleIdentifier": "is.hawkins.greene-co-alerts"
    },
    "android": {
      "package": "is.hawkins.greene-co-alerts"
    }
  }
}

Anyone smarter than me have an idea what’s up?

For what it’s worth, the code here is open sourced at https://github.com/hawkins/greene-county-alerts on the icon branch.

2

Worth noting, the build error on expo’s side of things lists a few worrying characteristics:

  • The SDK version is wrong. it lists 23.0.0 when I’m on 25.0.0.
  • The package name and version is ripped from package.json instead of app.json.
  • Some keys from app.json like androidStatusBar appear, but others like sdkVersion and android.package do not.

Here is what expo’s web build service lists as the manifest:

{
  "androidStatusBar": { 
    "backgroundColor": "#E67E22",
    "barStyle":"light-content"
  },
  "githubUrl": "https://github.com/hawkins/greene-county-alerts", 
  "name": "greene-co-alerts",
  "primaryColor": "#E67E22",
  "sdkVersion": "23.0.0",
  "slug": "greene-co-alerts",
  "version": "0.1.0",
  "id": "@hawkins/greene-co-alerts",
  "revisionId": (omitted),
  "publishedTime": (omitted),
  "bundleUrl": (omitted),
  "releaseChannel": "default"
}
3

OK. So here’s what I was missing:

Despite running exp start in another console, I also have to first run exp publish so the latest build is live on expo’s server. That seems wrong to me though - why can’t I build a native app of my working-code to test if the native build will even work? Shipping it to production for the sake of testing is a red flag to me, so surely I went wrong somewhere else?

Additionally, I had to list android.package at app.json#android.package and app.json#expo.android.package for builds to work (same for iOS bundleIdentifier). This is because the exp client checked for the existence of the key in one place and would reject submitting an exp build:ios request unless it was present. However, when it was present and the build submitted, the build logs on expo’s website would not have the bundleIdentifiers at all. When I put them in both spots, then they passed the preliminary client-side validation as well as showed up in build logs, as if expo was accidentally checking the wrong place in one of the clients?

I don’t know, I don’t want to sound like I’m blaming expo here since again I’m new to the native process, but after scouring documentation and coming to this conclusion of my own accord, I’m concerned there’s a mistake somewhere either in unclear docs or expo just accidentally checking the wrong path on one end. Regardless, this issue is solved. Back to loving mobile development in JS!

1 Like
4

Despite running exp start in another console, I also have to first run exp publish so the latest build is live on expo’s server. That seems wrong to me though - why can’t I build a native app of my working-code to test if the native build will even work? Shipping it to production for the sake of testing is a red flag to me, so surely I went wrong somewhere else?

I’d recommend reading our docs on release channels. You will have to push your code up to Expo’s servers still but you can do that without affecting your production app:
https://docs.expo.io/versions/latest/guides/release-channels.html

Additionally, I had to list android.package at app.json#android.package and app.json#expo.android.package for builds to work

That definitely sounds like a bug. Are you sure you need the android.package one? Which step failed without that?

5

I’d recommend reading our docs on release channels.

Thanks, that looks like it’ll do the trick there.

Are you sure you need the android.package one?

Sorry, any time I said android.package, I also meant ios.bundleIdentifier as well. Of course in this case it maybe only looks for the iOS one since I was trying to build iOS, but I moved them together since I’ll also want to build android anyway down the road.

Which step failed without that?

exp publish required that I have the keys under app.json#expo.ios.bundleIdentifier, as I expected. However, when I would run exp build:ios, the identifier and package name would not show up in the manifest on the expo website’s build logs. They did not show up until I included them at both the root level next to .expo as well as below .expo. (Or so I thought…)

But, just now I realized the real issue. I had my ios.bundleIdentifier as is.hawkins.green-co-alerts. After removing anything after the -, such that the new package was is.hawkins.green, the issue was resolved. I just confirmed this by using my original desired package name and received validation errors on client side when publishing, like I originally saw and posted this issue because of. So long story short, I must have broken the scientific method and tested that alongside the redundant-config I described earlier, and thus I came to the wrong conclusion.

Sorry for the confusion and “bug!” crying! I guess it all boils down to that I thought reverse DNS records could have hyphens in them.

6

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.