Open brentvatne opened 3 months ago
Hey, thank you for opening this issue! 🙂 To boost priority on this issue and support open source please tip the team at https://issuehunt.io/r/goatandsheep/react-native-dotenv/issues/501
To provide some more context, Expo uses internal environment variables that are not considered public (and therefore should never end up in the bundle). If these variables can be left untouched, we should have a way to get Expo Router and react-native-dotenv to work together.
Basically, all EXPO_*
variables should be left alone, with the gray area being EXPO_PUBLIC_*
variables. This is mostly defined by users using the default .env integration in Expo.
Does it work if you add these to blocklist? I'm happy to add this hint to docs if it works.
This babel plugin is meant to be simple and non specific. React native dotenv is meant to encourage best practices and you're welcome to go around this using blocklist. Expo-variables is a great alternative, but I'm not sure this is a fault of the library just yet. If you can provide a sample I'd be happy to take a look.
My bad I didn't see you provided a repro project. I'm taking a look now
I also didn't read that blocklist didn't work for you. That is concerning.
Yeah, I'm not exactly sure what's going on. In Expo, we do some bundling and possible static rendering (basically evaluating parts of bundle code in Node). Not sure if that might have anything to do with it. So far, neither safe
+ path
, blocklist
, or allowlist
worked for me, unclear why.
It would be nice if this library can work in Expo, if users need more control over it.
I'm having the same problem and since my project is still under development I've unshifted EXPO_PUBLIC_
to my env variables, as specified in https://docs.expo.dev/guides/environment-variables/.
I was facing the same problem. FYI, the incompatibility of react-native-dotenv
with expo-router
can load a default screen of expo
, and not your normal dev app you're building.
As an alternative for react-native-dotenv
, they're the default Expo CLI's built-in environment variable support or react-native-config for bare react native app.
@mayel15 unfortunately expo's built in env variables is not ideal, rn dotenv is way better.
@a-eid - can you explain the limitations that you're encountering? you could try disabling them, i'm not sure if that will help here though: https://docs.expo.dev/guides/environment-variables/#disabling-environment-variables
@brentvatne in expo we don't have the ability to load arbitrary .env files. for example .env.qa
or .env.staging
you can only load standard .env files .env.production
, .env.test
or .env.development
.
however with RN dotenv, we're able to do so use the APP_ENV
env variable.
I was facing the same problem. FYI, the incompatibility of
react-native-dotenv
withexpo-router
can load a default screen ofexpo
, and not your normal dev app you're building.As an alternative for
react-native-dotenv
, they're the default Expo CLI's built-in environment variable support or react-native-config for bare react native app.
+1 Fortunately, I was able not to depend on react-native-dotenv.
+1 here, our app is dependent on this package for reasons outlined by @a-eid. Is there something in the works for a fix? Would love to update to expo 51 asap.
Describe the bug
Cross-posting from the Expo repository: https://github.com/expo/expo/issues/28933
To Reproduce Steps to reproduce the behavior:
npx create-expo-app
cd my-app
npm install react-native-dotenv
npx expo start --ios
/app
(without the plugin, you will see tabs and theapp/(tabs)/index.tsx
screen.https://github.com/brentvatne/repro-dotenv
Expected behavior react-native-dotenv should play nicely with expo-router.
Screenshots n/a
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context Given this incompatibility, we are currently recommending that developers using Expo Router use Expo CLI's built-in environment variable support.
I think that one way to fix this issue would be to change the default behavior to whitelisted env vars only. In my opinion, not having this default can be a footgun.