mode staging not working

[deka]

Version

3.4.1

Environment info

 System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz
  Binaries:
    Node: 8.11.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.12.3 - C:\Users\dirayer\AppData\Roaming\npm\yarn.CMD
    npm: 6.7.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Not Found
  npmPackages:
    @vue/babel-helper-vue-jsx-merge-props:  1.0.0-beta.2
    @vue/babel-plugin-transform-vue-jsx:  1.0.0-beta.2
    @vue/babel-preset-app:  3.4.1
    @vue/babel-preset-jsx:  1.0.0-beta.2
    @vue/babel-sugar-functional-vue:  1.0.0-beta.2
    @vue/babel-sugar-inject-h:  1.0.0-beta.2
    @vue/babel-sugar-v-model:  1.0.0-beta.2
    @vue/babel-sugar-v-on:  1.0.0-beta.2
    @vue/cli-overlay:  3.4.1
    @vue/cli-plugin-babel: ^3.4.0 => 3.4.1
    @vue/cli-plugin-eslint: ^3.4.0 => 3.4.1
    @vue/cli-service: ^3.4.0 => 3.4.1
    @vue/cli-shared-utils:  3.4.1
    @vue/component-compiler-utils:  2.6.0
    @vue/eslint-config-prettier: ^4.0.1 => 4.0.1
    @vue/preload-webpack-plugin:  1.1.0
    @vue/web-component-wrapper:  1.2.0
    eslint-plugin-vue: ^5.0.0 => 5.2.2
    vue: ^2.5.22 => 2.6.7
    vue-cli-plugin-vuetify: ^0.4.6 => 0.4.6
    vue-eslint-parser:  2.0.3
    vue-hot-reload-api:  2.3.3
    vue-i18n:  8.8.2
    vue-loader:  15.6.4
    vue-router: ^3.0.1 => 3.0.2
    vue-style-loader:  4.1.2
    vue-template-compiler: ^2.5.21 => 2.6.7
    vue-template-es2015-compiler:  1.9.1
    vuetify: ^1.3.0 => 1.5.3
    vuetify-loader: ^1.0.5 => 1.2.1
    vuex: ^3.0.1 => 3.1.0

Steps to reproduce

in vue.config.js :

module.exports = {
    publicPath: process.env.NODE_ENV === 'staging'
        ? '/staging-path/'
        : '/'
    } 

run command : "vue-cli-service serve --mode staging"

What is expected?

publicPath == "/staging-path/"
process.env.NODE_ENV == "staging"

What is actually happening?

publicPath == "/"
process.env.NODE_ENV == "development"

---

It seems to me that "--mode staging" worked in a previous version

[haoqunjiang]

https://cli.vuejs.org/guide/mode-and-env.html#modes

When running vue-cli-service, environment variables are loaded from all corresponding files. If they don't contain a NODE_ENV variable, it will be set accordingly. For example, NODE_ENV will be set to "production" in production mode, "test" in test mode, and defaults to "development" otherwise.

This logic hasn't been modified in 9 months so I'm not sure what you mean by "worked in a previous version" https://github.com/vuejs/vue-cli/blame/dev/packages/%40vue/cli-service/lib/Service.js#L123

Next time please provide a reproduction repo when opening an issue.

[deka]

Thanks @sodatea
With :

NODE_ENV=staging

in the file .env.staging, it works as expected.
You say no change between 9 months ... i am scepticism.
Thanks

[IgorDePaula]

For me, .env.staging not works, simple throw error of module stating not found

[android0007]

For me, .env.staging not works, simple throw error of module stating not found

I also encounter this error. this is what i did:

npx vue-cli-service build --mode staging

https://cli.vuejs.org/guide/cli-service.html#using-the-binary

[omkardusane]

this (putting env in a file env.staging) has been observed to work with vue-cli 4 and not vue-cli 3

[sksallaj82]

This is happening with me too, I run this:

vue-cli-service serve --mode mydev

and when I go into the vue.config.js to check "process.env.NODE_ENV", it shows up as "development" instead of "mydev".

However, if I run:

vue-cli-service build--mode mydev

it works as expected.

I have these libraries in my package config:

"@vue/cli-plugin-babel": "^4.2.3",
"@vue/cli-service": "^4.2.3",

[haoqunjiang]

https://cli.vuejs.org/guide/mode-and-env.html#modes

When running vue-cli-service, environment variables are loaded from all corresponding files. If they don't contain a NODE_ENV variable, it will be set accordingly. For example, NODE_ENV will be set to "production" in production mode, "test" in test mode, and defaults to "development" otherwise.

It does not make sense to set NODE_ENV to other value than these three strings. Because it would break the common practice in the ecosystem and may lead to unexpected bugs.

[sksallaj82]

Ah, gotcha, the staging, and production values work, but as you pointed out it doesn't with anything else.

Though the reasoning is because I have 5 environments and the logic is in there to help out.

local - no auth -- local host same port as localDev
localDev - has auth -- local host same port as local
development - has auth -- server ip
staging - has auth -- server ip
production - has auth -- server ip

I think I can override the system I have by making use of .env.{environment}.local ... hmmmm

[sksallaj82]

Just thought about it, just doesn't seem feasible to me.

if I have:

env. -- localhost:1234 -- no auth -- my machine
env.development -- example.com -- dev aws machine
env.development.local -- localhost:1234 -- with auth -- dev aws machine

I'm not sure how I should differentiate, and this adds extra manual labor of excluding locals when I use my publishing method. I do a lot of preparations before I move to each stage.

If local works (url A), I push to dev on my machine (url A), then I replicate that dev on the dev machine (url A) sharable with internal QA, then I replicate it to staging (url C) sharable with external QA, then I replicate on prod (url D) sharable with everyone with access. I use those environment names to continuously add more and more security measures across the application through each of those phases. I'm not sure what other methods to try to be honest if the build scripts were to break in future releases.