serverless-dotenv-plugin
serverless-dotenv-plugin copied to clipboard
NODE_ENV and stage collides to each other
Is your feature request related to a problem? Please describe.
NODE_ENV
and stage
are two different things,
NODE_ENV
usually controls let's say for the sake of simplicity just "optimizations"
-
NODE_ENV=development
-> very verbose, non optimised -
NODE_ENV=production
-> silent, optimised
stage represents where the application should be deployed, it can specify different database, file storage etc.
-
stage=development
- for development purposes -
stage=qa
- for acceptance testing -
stage=staging
- preproduction testing -
stage=production
- production environment
so 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 if NODE_ENV
has been specified as well. and it must be specified due to other toolings that required that env variable.
getEnvironment(options) {
return (
process.env.NODE_ENV || options.env || options.stage || 'development'
);
}
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 option
custom:
dotenv:
# default: false
ignoreNodeEnv: true
and to adjust getEnvironment()
like this
getEnvironment(options) {
return (
!this.config.ignoreNodeEnv && process.env.NODE_ENV || options.env || options.stage || 'development'
);
}
Describe alternatives you've considered Writing own parser donEnvParser
I'm not convinced either way around the name of the environment variable NODE_ENV
. I can see how this decision was made, as NODE_ENV
is a de facto way of describing the environment the code is going to run in. I was unable to get more context in https://github.com/neverendingqs/serverless-dotenv-plugin/issues/24 or https://github.com/neverendingqs/serverless-dotenv-plugin/commit/e63d52d2be2ab866b8a88ea0bff1cc253ef06336 when this was introduced.
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 process.env.NODE_ENV
was second-last instead of first in getEnvironment()
, would that work? If so, I would like do this as part of v4 (https://github.com/neverendingqs/serverless-dotenv-plugin/projects/1), especially since v4 changes can be pulled in right away in v3 with the v4BreakingChanges
option.
As a workaround, you should be able to set NODE_ENV
inside your dotenv file. That way, you can either use command line arguments or set NODE_ENV
to resolve which dotenv files to use, and then this plugin will set NODE_ENV
for your Lambda functions.
I am interested in your use case as well, specifically why NODE_ENV
is being set outside of dotenv files.
@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 generate_artefacts
, etc. not familiar with .env files then it must be declared outside
scripts: {
"start": "yarn start:development",
"start:development": "export NODE_ENV=development DEPLOYMENT=development; yarn _start",
"_start": "generate_artifacts && sls offline --stage $DEPLOYMENT",
}
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 stage
and let users choose between ${env:NODE_ENV}
or ${self:provider.stage}