dotenv support | Voters

dotenv support

Tim Brandin

Please add dotenv support, or another method of storing environment variables separate from the code.

July 3, 2018

Jaroslav Khorishchenko

Good idea. It follows the idea of "The Twelve-Factor App" and "Config" specifically. It is a bad idea to keep credentials directly in the repo source code. If you will keep Google API token in the source code you will get a warning from Google. So it is better to add required

.env

file during the build process.

More about it here: https://12factor.net/config

Wodin

Jaroslav Khorishchenko: Does the recent addition of support for app.config.js help with this? https://github.com/expo/expo-cli/pull/1342

Jaroslav Khorishchenko

Wodin: I didn't know about this feature. But it looks great, thank you!

Nikola Mihajlovic

I think the key is that this config shouldn't be checked into source control. Consider a developer wants to change server URL but only for development. Different developers will want to use different server URL while developing, so it can't be checked in source control. Production configuration I would definitely put inside code, however development config needs to be factored into a separate file which is not in source control.

I found: https://github.com/zetachang/react-native-dotenv which does the job.

goatandsheep

Nikola Mihajlovic: for anyone here in 2021, repo link has moved to https://github.com/zetachang/react-native-dotenv

Brent Vatne

it's not clear to me what this means. the environment that your code runs in, on your phone, doesn't have any environment variables. i think you don't actually want environment variables because they don't really make sense in this context. if you can articulate clearly what exact behavior you want it would be helpful

Tim Brandin

Brent Vatne: in different environment, aka test version, staging, production-releases one might use different globally scoped variables like api-url, translation-system-url, public keys to different services. right now it's really difficult to use different variables because the build caches the files with the variables and one have to touch all of them for them to change. One typical example is when working towards a local api, which in practice if you want to be able to test with that api on your phone one need to use the IP of your computer (which does change if you work in multiple different locations).

Or how do you handle this? Am I doing something different then everyone else?

Brent Vatne

Tim Brandin: you can put this all in app.json under extra (https://docs.expo.io/versions/v28.0.0/workflow/configuration#extra) and then select the appropriate set of constants to use depending some constants or release channel - https://docs.expo.io/versions/v28.0.0/sdk/constants. another alternative to putting it in app.json is just create a js file

Tim Brandin

Brent Vatne: I ended up using a .js file, works better that way and it reloads the app when it is changed.

Daniel Cefram Ramirez

Brent Vatne: I think the best use-case for this is when you have to store some sensitive data, but you wouldn't want to commit that to the repository. The FAQ in the dotenv project has some explanation about this: https://www.npmjs.com/package/dotenv#should-i-commit-my-env-file

For a mobile app, we won't be hardcoding passwords in a .env file, but we might be "hardcoding" some 3rd party service API Keys (maybe for a serverless backend service that we might be using). For a private project, committing the API Key could be fine, but for public projects, that would not be the case. You wouldn't want someone else using your tokens for other projects right? Since we would most likely commit the app.json to the repo, I think the OP has some valid use-case for this feature request.

Brent Vatne

Daniel Cefram Ramirez: you can accomplish this same thing using an

app.json.example

file and requiring that when people clone your app they copy it and rename to

app.json

and then put the private data in, which is never committed. this is a very common pattern. if someone wants to open a pr to make

app.json

somehow support env vars then we may be able to look into it, but given that it just supports a different workflow with, as far as i can tell, no advantages over a much technically simpler workflow, it's not something i plan on spending time on myself.

Daniel Cefram Ramirez

Brent Vatne: now that you said it, you're right. Instructions could be written in the readme for contributors anyways about the app.json.example file and the missing app.json if it was used to store sensitive data. Plenty of alternatives to accomplish the use-case I stated.

Jacob Arvidsson

Daniel Cefram Ramirez: But if you are using a CI tool, then you want it to be environment variables, so you can add it to your secrets?

Pravin Tiwari

Brent Vatne: Hi, I was looking for a similar thing, is there any support of .env in app.json yet?
or as you said anyone can add an "envPath" key support in app.json, which will be like "envPath": "/some/path/.env", and it should do the trick.
right now, I'm using js file.

jdrydn

inline-dotenv is plenty enough - I'm loading all those into a

config.js

and then performing the destructuring by importing my own config file 😉

Tim Brandin

Though I realized that Expo does not rebuild unless we change those actual files that user process.env to get them to update. A typical use-case is to have it use my IP to the API on my computer when working locally.

Tim Brandin

dang it, I was using destructuring to get the variables, inline-dotenv does not support destructuring yet.

Tim Brandin

i.e. using inline-dotenv one can get process.env to install all the variables into places where they are used correctly with babel, but this does not seam to work with the exp builder.