The premise

The reason is that I am looking at the source code of VUe-i18n. In the script of package.json,

"scripts": {
    "dev": "cross-env BABEL_ENV=test webpack-dev-server --inline --hot --open --content-base ./test/unit/ --config config/webpack.dev.conf.js"
},
Copy the code

To solve the problem

If the environment variable is set to NODE_ENV=production, Windows commands may block. (Except Bash on Windows, which uses native Bash)

Cross-env uses a single command without worrying about setting environment variables. Set up as if running on a POSIX system, cross-env does the right thing.

A, install,

npm install --save-dev cross-env
Copy the code

NOTE: cross-env 7 only supports node.js >=10 cross-env 6 requires NPM install –save-dev cross-env@6

Second, usage,

// package.json
"scripts": {
	"build": "cross-env NODE_ENV=production webpack --config build/webpack.config.js"
}
Copy the code

2.1, configuration,Babel

"scripts": {
	"dev": "cross-env BABEL_ENV=test webpack-dev-server --inline --hot --open --content-base ./test/unit/ --config config/webpack.dev.conf.js",}Copy the code

Babel will enable configuration under ENV based on the current environment.

Babel can be configured using the.babelrc file. You can also set BABEL_ENV=test in scripts.

The current environment is available through process.env.babel_env. If BABEL_ENV is not available, it will be replaced with NODE_ENV. If NODE_ENV is not set, the default value is development.

This comes from the Express Web server framework and uses NODE_ENV to determine whether the server should be running in development or production mode. At run time, the script looks for this value by checking process.env.node_env.

(Updated continuously…)

reference

[1]. Jest – Getting Started

[2]. Building Better Bundles: Why process.env.NODE_ENV Matters for Optimized Builds

[3]. Node – process.env