-
Notifications
You must be signed in to change notification settings - Fork 466
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
Does parcel use dotenv, or dotenv flow? The documentation is incomplete and confusing #1013
Comments
Also Right now the behavior mimics |
This is where the loading happens: https://github.com/parcel-bundler/parcel/blob/e294eafd9a49c056fb4b223c5ace5c0653428ede/packages/core/core/src/loadDotEnv.js#L10 |
Hmm, so I see that the code is actually the same as in create-react-app and next.js. Same behavior for test with the same comment verbatim:
I thought they used to use The behavior is definitely more in alignment with I think the biggest thing missing here is a section on source control, and maybe expand on precedence order. Both create-react-app and next.js have sections in their documentation going over both in more detail. |
This is meant to fix parcel-bundler#1013
I just ran into this question too. How about this proposed edit to the docs? #1079 |
Is Parcel using dotenv as it claims, or dotenv-flow? It links to
dotenv
but supports multiple env files in the same manner asdotenv-flow
, which is not included behavior withdotenv
and actively warns against it. Howeverdotenv-flow
has specific rules on which env files have higher precedence. Command line env variables have the highest precedence, and.env.local
is still loaded for test. This is the behavior that next.js and create react app uses.I think parcel needs to go with one or the other, link to it, and use the same logic. If not remove the link and just document it's own rules : What files can be source controlled? What files overwrite others? Are command line env variables overwritten if defined etc.
Also what is the rationale behind not using
.env.local
for test? Env variables loaded via jenkins/aws/etc are higher priority than ones defined in env files withdotenv-flow
..env.local
will have unsourced secrets and may need to be different than the actual test environment (dev/qa/staging etc), but API keys may still be necessary for any integration or end-to-end testing. Precedence order should make sure it all works correctly which is the main concern when using multiple.env
files. I'd probably end up with two local env files with the same configuration and I'm not sure I'm understanding what the benefit is.The text was updated successfully, but these errors were encountered: