Could the CLI source from `.env` and `.env.local` like the Expo CLI does?

[shirakaba]

We're trying to build a native module, react-native-node-api, that treats both Expo and non-Expo apps as equal citizens, but our options for providing a good DX are limited on the non-Expo side because – as far as I can tell by searching – the RNC CLI templates do not source from .env or .env.local in their Gradle and Xcode build scripts.

Resources:

• Expo environment variables docs
• How Expo CLI loads env vars:
  • for run:android
  • for run:ios
  • for prebuild

[thymikee]

How would loading the .env improve the DX in your case? RNC CLI would need to do something with these variables, unless it's enough to pass the process.env to some process through execa/spawn.

[shirakaba]

In order to use a custom Hermes, users need to set the REACT_NATIVE_OVERRIDE_HERMES_DIR environment variable in a way that Gradle will pick it up. It's not exposed to settings.gradle, so Gradle plugins have no way of setting it up for you. More discussion in this PR: callstackincubator/react-native-node-api#188 (comment).

One option is for the user to export it into their current shell session and build the app during that shell session. However, it will be lost with the shell session so they'll have to set up the environment variable again next time.

Another option is for the user to write it into their ~/.zshrc, but this would affect their other React Native apps, too.

So both options are bad.

Alternatively, when you run npm run android, RNC CLI could source .env.local and pass those environment variables onto the Gradle build. Specifically, when RNC CLI executes a child process that calls ./gradlew, it could configure that child process to inherit the current shell environment.

If we did all that (just like the Expo CLI does, to my understanding), then it would allow us to reach a better solution that could work for both Expo and Expo-free projects.