Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic env file resolution is in reverse order of precedence #131

Open
neverendingqs opened this issue Feb 16, 2021 · 7 comments
Open

Comments

@neverendingqs
Copy link
Owner

neverendingqs commented Feb 16, 2021

The README says

The env resolution pattern follows the one used by Rail's dotenv and create-react-app

But the code says

const dotenvFiles = [
`.env.${env}.local`,
`.env.${env}`,
// Don't include `.env.local` for `test` environment
// since normally you expect tests to produce the same
// results for everyone
env !== 'test' && `.env.local`,
`.env`,
]
and
const envVarsArray = envFileNames.map((fileName) => {
const parsed = dotenv.config({ path: fileName })
return this.variableExpansion
? dotenvExpand(parsed).parsed
: parsed.parsed
})
return envVarsArray.reduce((acc, curr) => ({ ...acc, ...curr }), {})

That last .reduce() call means we're actually resolving the files in reverse order of precedence, since env vars in lower priority files are overwriting the ones in higher priority files.

The fix is potentially a breaking change, and so requires a major version bump.

@danilofuchs
Copy link
Contributor

When I implemented this, I used the create-react-app code as a sample. I now see this reduce may be causing issues.

https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/config/env.js

@feeh27
Copy link

feeh27 commented Mar 25, 2021

Is that why .env.local takes precedence over .env?

@danilofuchs
Copy link
Contributor

Is that why .env.local takes precedence over .env?

.local should always have higher priority then their non-local equivalents. This is by design to allow a single dev to override a shared env

@feeh27
Copy link

feeh27 commented Mar 25, 2021

Is that why .env.local takes precedence over .env?

.local should always have higher priority then their non-local equivalents. This is by design to allow a single dev to override a shared env

I use this plugin in my local environment and when I deploy to the environments, however .env.local is replacing the values of my .env file that is generated at run time in the deploy pipeline, the correct one wouldn't be .env take priority over .env.local?

@danilofuchs
Copy link
Contributor

danilofuchs commented Mar 25, 2021

@feeh27 .env.local is intended to override .env. This is by design, not a bug.

You should not commit .env.local to your git repo. If you are running the deployment on an CI, it should not have access to .env.local at all.

If you are running the deployment locally, I suggest you use .env.development and .env.development.local when developing and then .env or .env.production when deploying. You can manage which file is read by using the --stage argument for serverless

@feeh27
Copy link

feeh27 commented Mar 25, 2021

I understood, really the way the library works and the projects I work on understand the .env.local and .env differently.

I have already managed to adjust this in my pipelines deleting the .env.local.

Thank you for your attention.

@henrypenny
Copy link

I'm still seeing .env values override .env..local. In my case .env.test.local.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants