expo: Manifest missing originalFullName in EAS Build Development Client

It’s not resolved.

It seems you’re using eas anyway.

Yes but I do have this issue using eas! By the way, I’m not trying to use the same variables as you, I try to fetch a extra.apiEndpoint custom var we defined.

My https://github.com/expo/expo/issues/13513#issuecomment-1237238178 works with that without any hardcoding. I’m using that solution in production too 😃

Indeed, you don’t have value hardcoded on your code. However, what a complex custom logic just for a not provided manifest property. 😕

I think I’ll just be careful of doing a eas upate command just after the eas build to be sure the app load the configuration correctly until I do the upgrade to SDK 46.

Thanks for the help! 👍

@isaachinman as I expected, expo-updates (the package) is staying, but the service (free OTA pushes) is going away. The newer (and supposedly better) EAS Update doesn’t expo manifest anymore (by its RFC–based spec/design).

This is what I’ve started doing:

yarn add dotenv babel-plugin-transform-inline-environment-variables

Then, edit your babel.config.js

module.exports = function (api) {
  api.cache(true);
  return {
    presets: ['babel-preset-expo'],
    plugins: [
      'react-native-reanimated/plugin',
      'transform-inline-environment-variables', // <= this was added
    ],
    env: {
      production: {
        plugins: ['react-native-paper/babel'],
      },
    },
  };
};

Next, create app.config.ts, and fill it in:

import type { ExpoConfig, ConfigContext } from '@expo/config';

// Load .env into process.env
import dotenv from 'dotenv';
dotenv.config();

function assert(value: string | undefined): string | never {
  if (typeof value === 'string') {
    return value;
  }

  throw new Error('Expected value, but ENV variable is not set');
}

export default ({ config }: ConfigContext): ExpoConfig => ({
  ...config,
  name: assert(process.env.EXPO_NAME),
  description: assert(process.env.EXPO_DESCRIPTION),
  slug: assert(process.env.EXPO_SLUG),
  owner: assert(process.env.EXPO_OWNER),
  // ... more if you want
})

…and create the corresponding .env file:

EXPO_NAME="Your App Name"
EXPO_DESCRIPTION="Your app description"
EXPO_SLUG="your-app-slug"
EXPO_OWNER="user-account-name-on-expo.dev"
# ... more if you want

…and finally create a new file src/config.ts

export const EXPO_SLUG = process.env.EXPO_SLUG!;
export const EXPO_OWNER = process.env.EXPO_OWNER!; 

export const EXPERIENCE_ID = [EXPO_OWNER, EXPO_SLUG].join('/');

It’s not perfect because technically expo could have a different experience ID under the hood, but overall this method works with everything else you need from the manifest, and also shows how you can replace the old "extra" key things.

How does this work?

• dotenv/config in app.config.ts makes sure process.env is filled with the local .env file (no-op if there is none). This is necessary during local development, or build steps.
• The babel plugin transform-inline-environment-variables searches for process.env.SOME_KEY and replaces it with the actual value of SOME_KEY during that process. That means that in your build output, the files no longer have any process.env reference.
• If you push an update over the air, a new config.ts file will be downloaded (with actual values, not process.env references).
• Rejoice.

@brentvatne

Is there any official documentation on this subject?

It seems the absence of manifest essentially breaks several/many expo packages when upgrading from 45 to 46-dev-client, and I cannot find any official guidance.

Is the workaround listed above seriously what’s still needed, over a year later?

After an upgrade to eas update and Expo v46, I’m back to the originalFullName issue, following https://github.com/expo/expo/issues/13513#issuecomment-1146881040.

The variable to use is now Constants.expoConfig.originalFullName, stop me if I am wrong.

This variable:

• Is present on eas build output
• Is present on eas update output usage with Expo Go
• Is not present when used locally with Expo Go

This variable is supposed to be auto-generated in any circumstance, am I right? Without that value, I have no way to provide a unique id to my notifications service, meaning no way to test notifications locally.

The only workaround I found looks like the original one posted by @SleeplessByte:

// Directly on App.tsx or index.tsx according to your code structure.
import Constants from 'expo-constants';

if (Constants.expoConfig && !Constants.expoConfig.originalFullName) {
  Constants.expoConfig.originalFullName = '@org/project';
}

However, I am not supposed to do that. I am missing something or are we facing an Expo bug here?

Is there any official documentation on this subject? It seems the absence of manifest essentially breaks several/many expo packages when upgrading from 45 to 46-dev-client, and I cannot find any official guidance.

@isaachinman and @soullivaneuh From what I’ve read, either from the Expo docs (on the EAS debugging/troubleshooting something guide) or from Kim on their Discord (link), the way to do things from Expo SDK 46 and onwards, is to use Constants.expoConfig instead of Constants.manifest since that will be null after an update. Here’s the Typescript interface for whomever needs it.

Edit: Constants.expoConfig will handle resolving itself regardless of whether you’re using EAS updates or the classic updates service.

Thanks for raising! While we work to make this smoother I’d recommend using the native option rather than setting originalFullName yourself.

https://docs.expo.io/versions/latest/sdk/auth-session/#authsessionmakeredirecturi https://docs.expo.io/versions/latest/sdk/auth-session/#authsessionredirecturioptions