React-native-config: Should I commit the .env file?

[davicorreiajr]

I've already seen people telling to commit the .env file (for React projects, for example), and to not commit (for servers).

For react-native projects, what's the best practice?

[jpudysz]

Do not commit it. Keep it in .gitignore

[DiogoAbu]

Ignore the .env and create a example file removing only the values.
That way the users will know the variables they need without exposing your secrets.

.env (ignored)

SUPER_SECRET=o2pqB1SNMAqJoYpMZej/cg==

.env.example (committed)

# Copy and rename this file to '.env'
SUPER_SECRET=generate one at https://generate.plus/en/base64

[fattomhk]

Keep in mind this module doesn't obfuscate or encrypt secrets for packaging, so do not store sensitive keys in .env. It's basically impossible to prevent users from reverse engineering mobile app secrets, so design your app (and APIs) with that in mind.

So, you can commit it.

[FranciscoSimaoPerez]

Keep in mind this module doesn't obfuscate or encrypt secrets for packaging, so do not store sensitive keys in .env. It's basically impossible to prevent users from reverse engineering mobile app secrets, so design your app (and APIs) with that in mind.

So, you can commit it.

But imagine you have the repository public, if you commit it then people can easily access it, of course don't committing will not completely protect it but is better than giving direct access to your envs and api key.

You can commit it but in my opinion that isn't the best approach.

[habibalamin]

You should not be storing your API keys in this file in the first place.

[fattomhk]

Keep in mind this module doesn't obfuscate or encrypt secrets for packaging, so do not store sensitive keys in .env. It's basically impossible to prevent users from reverse engineering mobile app secrets, so design your app (and APIs) with that in mind.

So, you can commit it.

But imagine you have the repository public, if you commit it then people can easily access it, of course don't committing will not completely protect it but is better than giving direct access to your envs and api key.

You can commit it but in my opinion that isn't the best approach.

The point is, the runnable is hosted at client side. If an api key leaking would damage your data or billing account, never put it in an env file or even source code.

For example, a Google map api key, it would damage my billing account if someone got it. So Google would protect you by the api key and whitelisting domain / package / fingerprints