NODE_ENV and stage collides to each other

[rostislav-simonik]

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

[neverendingqs]

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 #24 or e63d52d 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.

[rostislav-simonik]

@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.

[danilofuchs]

I think we could add a new option stage and let users choose between ${env:NODE_ENV} or ${self:provider.stage}