Redundant Property Definitions in `local.properties` and `.env` Files Leading to Developer Confusion

[dzuluaga]

In the sample app, developers are required to define certain properties in both the local.properties and .env files. This redundancy not only creates confusion but also introduces a higher potential for errors. If developers mistakenly enter different values in these files, it could lead to unexpected behavior or the abandonment of the module altogether.

For example, the DROPBOX_CLIENT_SECRET is defined in .env but is missing from local.properties.sample. Following the current setup, this results in the following error during build:

460 actionable tasks: 456 executed, 4 up-to-date
info Connecting to the development server...
info Starting the app on "FMR0223B28045079"...
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.openmobilehub.reactnative.storage.sample/.MainActivity }
 BUNDLE  ./index.js

error: src/contexts/auth/getAuthClient.ts: /Users/diegozuluaga/tools/git/react-native-omh-storage/apps/sample-app/src/contexts/auth/getAuthClient.ts: "DROPBOX_CLIENT_SECRET" is not defined in .env
  1 | import {
  2 |   DROPBOX_CLIENT_ID,
> 3 |   DROPBOX_CLIENT_SECRET,
    |   ^^^^^^^^^^^^^^^^^^^^^
  4 |   GOOGLE_CLIENT_ID,
  5 |   MICROSOFT_CLIENT_ID,
  6 | } from '@env';

Current Setup:

• local.properties.sample

  GOOGLE_CLIENT_ID=
  MICROSOFT_CLIENT_ID=
  MICROSOFT_SIGNATURE_HASH=
  DROPBOX_CLIENT_ID=
  

• .env.sample

  GOOGLE_CLIENT_ID=
  MICROSOFT_CLIENT_ID=
  DROPBOX_CLIENT_ID=
  DROPBOX_CLIENT_SECRET=
  

Additional Question:

Why does the build process not fail when a property is defined in local.properties but missing from .env? This behavior is inconsistent and can cause confusion, as developers might expect a failure if a required property is missing from one of the configuration files.

Problems:

1. Duplication of Effort: Developers need to define the same properties in two different files, increasing the likelihood of inconsistencies.
2. Potential for Errors: If values differ between the two files, this can lead to build errors or incorrect app behavior.
3. Incomplete Property Definitions: The DROPBOX_CLIENT_SECRET is not defined in local.properties.sample, leading to an undefined error during the build.

Suggestion:

To streamline the setup process and reduce the potential for errors, I suggest the following:

• Single Source of Truth: Use the local.properties file as the single source of truth.
• Automated .env Generation: Implement a script or build step that generates the .env file based on the values defined in local.properties.

This approach will simplify the configuration process, ensure consistency across files, and minimize the chances of errors due to mismatched property values.

[adamTrz]

Hi @dzuluaga
Thanks for reporting the issue
There's a reasoning why we have two files with env variables - both realms (Native Android and React Native) are using some of them. There are options to extract native env variables to be used in React Native world but we didn't want to force users to use one solutions - they should have been able to use their own preferred approaches. We strongly believe that current setup that we have is viable for basic use cases.

We have .env.sample and local.properties.sample files with values that should be populated, as for the error I believe it's quite descriptive and points developers to correct place.

Why does the build process not fail when a property is defined in local.properties but missing from .env? This behavior is inconsistent and can cause confusion, as developers might expect a failure if a required property is missing from one of the configuration files.

To answer above question - local.properties file is being resolved during build time by gradle while .env file is being accessed only at run time of application.

[dzuluaga]

Hey Adam,

Thanks for your explanation—it really helps clarify things.

I was thinking, to keep things simple and avoid any confusion, maybe we could use just one config file like .env for all our environment variables. Lots of React Native projects do this, using tools like react-native-config to share variables between React Native and native code.

Since our React Native code is already pulling Android configs from .env, unifying everything there might streamline the setup and reduce the chance of mismatched values. It's a pretty common approach in other projects, so it might be worth considering.

What do you think about trying this out? I'd love to hear your thoughts and see if we can find a solution that works for everyone.

Cheers,
Diego

[adamTrz]

I was thinking, to keep things simple and avoid any confusion, maybe we could use just one config file like .env for all our environment variables. Lots of React Native projects do this, using tools like react-native-config to share variables between React Native and native code.

But that's exactly the point I was trying to make - we would be forcing users to go with one library instead of other (eg. react-native-config) and adding additional package to sample app while we wanted the setup to be as simple as possible. For other use cases I think developers could go either with approach that we are going in Sample App OR use other solutions, like the one you've proposed for example :)

[dzuluaga]

My previous comment was also regarding the inconsistency between the fields in .env.sample and local.properties.sample. Would it be possible to reduce the need for copying and pasting different fields between the two? Even if a field isn't used in one of the files, we could guide the user to copy and paste the entire content to simplify the process.

[adamTrz]

I would disagree here
Both platforms are needing different sets of secrets and adding for example Microsoft_signature_hash to .env file could raise questions "why we need it here?"
This way it is clear which platform needs which secret :)