EAS Build Failing due to .env (react-native-dotenv, typescript, bare workflow)

Before posting your question, make sure you’ve read the documentation for both EAS Build & Submit.

If your Android or iOS build is failing- make sure you do your own research on the error message first before posting (this will give you a better understanding, and you might even find that someone else has already solved the issue!)

I’m using react-native-dotenv which adds a .env file to the root of my project. From reading the Xcode logs, it is clear that this file isn’t included in the build within EAS. Having read the docs on env variables, I tried implementing a constants.ts file which imports and exports my variables. I switched all imports from @exp to @utilities/constants. Before submitting a build via EAS again, I tried running the app locally via Xcode and I’m now getting this error which I can’t make sense of so I’m wondering if there is an additional step.

src/utilities/constants.ts: Property local of ExportSpecifier expected node to be of a type ["Identifier"] but instead got "StringLiteral"

Here is my constants.ts (with alternate values for the variables)

import {
} from '@env'

export {

Here is how the variables are being imported within my project:

import { VAR_1 } from '@utilities/constants'

Here is my babel.config.js:

module.exports = api => {
    return {
        presets: ['babel-preset-expo'],
        plugins: [
                    moduleName: '@env',
                    path: '.env'
                    extensions: ['.png', '.svg', '.ts', '.tsx'],
                    root: ['./'],
                    alias: {
                        '@types': './src/types',
                        '@utilities': './src/utilities'

And here is my environment variable types file env.d.ts:

declare module '@env' {
    export const VAR_1: string
    export const VAR_2: string
    export const VAR_3: string

Even if I do get this to build, I’m concerned that this set still won’t work with EAS build because it is still reading from a .env rather than process.env.VAR_1, as an example. Any input would be greatly appreciated, thanks.

1 Like

hi there,

i don’t totally understand everything that is being done here and most of it is unrelated to eas build, and rather it’s about module-resolver and react-native-dotenv.

the suggestion in Environment variables and secrets is to provide a fallback value if your environment variable is not available, it’s not opinionated at all about how you read from your env.

that said, very soon (maybe tomorrow) you will be able to pass in values in an env key in eas.json if you’d like to set env vars on your build. you can see the pr for the docs here: [docs] EAS Build configurable build environment by wkozyra95 · Pull Request #11845 · expo/expo · GitHub

1 Like

@notbrent Thanks for the reply. Given that that PR is just the docs, does that mean that I could already begin to utilize that functionality, it’s just not yet documented?

unfortunately not yet - here’s a pr that adds support for it to eas-cli: [eas-cli] configurable builder environment by wkozyra95 · Pull Request #230 · expo/eas-cli · GitHub - and the server component is only on staging

got it thanks, it seems you’ll still have to provide the actual values for these environment variables in eas.json so I have some work to do moving one token out of the client in the meantime. Will there eventually be an interface in the Expo dashboard for setting those values?

@danstepanov did you manage to get this working? The docs on setting env variables in eas.json (Environment variables and secrets - Expo Documentation) just hand off to the main https://docs.expo.io/guides/environment-variables page for accessing their values. That page has various suggestions on how to implement env variables - I’ve tried pretty much every combination on there but cannot pick up the env values I’ve set in eas.json in the built version of my app

@notbrent any chance we could get a specific docs for accessing env variables defined in eas.json rather than handing off to the general environment-variables page?

@russ_stuta - are you using the latest version of eas-cli? also, here’s a simple example:


  "builds": {
    "ios": {
      "release": {
        "workflow": "generic",
        "env": {
          "API_URL": "https://api.production.com"


export default ({ config }) => ({
  ...config, // extend app.json
  extra: {
    apiUrl: process.env.API_URL ?? 'http://localhost:3000'


import React from "react";
import { Text, View } from "react-native";
import Constants from "expo-constants";

export default function App() {
  return (
    <View style={{ flex: 1, alignItems: "center", justifyContent: "center" }}>

you can test this locally by running your project and you should see https://localhost:3000

then when you run it through eas build, you will see https://api.production.com

the reason we don’t have any specific information about how to access the environment variables set through eas.json is that there is no difference between how to do this after setting in eas vs otherwise, you just set them in eas.json to make them available on the eas build worker. it does, however, sound like we need to revisit our environment variables docs to make them more clear

Ah - interestingly the example you’ve given above is the one method I didn’t try! Mainly because the docs state:

“In the bare workflow, you don’t have access to the manifest via the expo-constants module.”

I instead attempted to access them using each of the babel plugin based and local dot env file techniques in the docs all of which worked locally but not in the built app

Should all of the techniques listed for accessing env variables “just work” then?

yeah they will all work as long as you set the env in eas.json

Hi I’m a maintainer of react-native-dotenv. I was able to recreate the issue and fix it by using export default in the constants.ts and then importing using import constants from '@utilities/constants' and constants.VAR_1

See this example



Thanks for response, I found lots of helpful information here, Really appreciate for help.