How we should work with different enviroments?

[maxim-usikov]

What problem does this feature solve?

More clearest way to work with different enviroments.

What does the proposed API look like?

I think we need only one .env file, that contain all kind of enviroment variables.
That file should not be tracked by VCS.
But we can have documented .env.example.

I mean build script should load variables only from one .env
NOT merging .env.local with .env.whatever
NOT loading multiple .env
JUST load .env and build

For CI, dev, stage, ..., or every other enviroment, you should preconfigure .env, thats all.
Dont need magic mode for vue-cli-service build --mode=internal.
vue-cli-service build should see .env and just build.

Should use dotenv.

The process for any kind of enviroment setup:

1. pull (vcs)
2. configure(.env)
3. build(vue-cli-service build)

# Usage:
# bash
vue-cli-service build
APP_ENV=/full/custom/path/to/your/env/vars vue-cli-service build
vue-cli-service build --env=/full/custom/path/to/your/env/vars 

// Possible implementation
const args = require('yargs').argv
require('dotenv').config({path: process.env.APP_ENV || process.args.env || '.env'})

// Usage:
// package.json
{
    "scripts": {
        "build": "vue-cli-service build",
        "build:first_variant": "vue-cli-service build --env=/full/custom/path/to/your/env/vars",
        "build:second_variant": "ENV_PATH=/full/custom/path/to/your/env/vars vue-cli-service build",
    }
}

[yyx990803]

People may want some variables checked in, some not. Your use case is not the only use case. If you don't need modes, just don't use it.