-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
NODE_ENV and stage collides to each other #150
Comments
I'm not convinced either way around the name of the environment variable I would argue however that command line arguments should probably override environment variables, as command line arguments are explicit while environment variables are implicit. If As a workaround, you should be able to set I am interested in your use case as well, specifically why |
@neverendingqs yes, if we increase precedence of command-line arguments over NODE_ENV in that case it's fine. specifying NODE_ENV within .env files is problematic because if you are using such other tools as
I'm using github branch dependency so no need for immediate merge, but if it would be somehow introduced in 4.0, then it would be great. |
I think we could add a new option |
Is your feature request related to a problem? Please describe.
NODE_ENV
andstage
are two different things,NODE_ENV
usually controls let's say for the sake of simplicity just "optimizations"NODE_ENV=development
-> very verbose, non optimisedNODE_ENV=production
-> silent, optimisedstage represents where the application should be deployed, it can specify different database, file storage etc.
stage=development
- for development purposesstage=qa
- for acceptance testingstage=staging
- preproduction testingstage=production
- production environmentso you can have mix like
stage=development
,NODE_ENV=development
stage=qa
,NODE_ENV=production
stage=staging
,NODE_ENV=production
stage=production
,NODE_ENV=production
because of
getEnvironment()
function, it's impossible to differentiate by stage ifNODE_ENV
has been specified as well. and it must be specified due to other toolings that required that env variable.Describe the solution you'd like
Not sure what would be the best, but I'd suggest completely remove
NODE_ENV
from that setup, but because we don't want to break existing usage, I'd introduce some optionand to adjust
getEnvironment()
like thisDescribe alternatives you've considered
Writing own parser donEnvParser
The text was updated successfully, but these errors were encountered: