Better management of front-end environment variable methods

This article mainly analyzes the problems encountered when using environment variables to manage front-end projects, and describes common tools to give solutions.

How to use environment variables

when building a webpack front-end project (or any Node-based project, this article takes the Webpack project as an example), it is generally necessary to provide two modes of operation: Development mode and production mode. It is common practice to set environment variables before executing commandsNODE_ENVto beproduction, such as executingNODE_ENV=production webpackcommand, and then in JavaScript code through theprocess.env.NODE_ENV === 'production'to judge is the production mode, otherwise the development mode. Different operations can be performed by distinguishing between different modes, such as starting the development server in development mode and forwarding the API, or compressing the merge code in production mode. In order to better unify the front-end Engineering command, you can add the command to start the development mode and production mode into the scripts field of the Package.json file, and then only need to executenpm startornpm run buildcan be. Defining environment variables is a good way to resolve the need to perform variance operations in your project. If you want to support member custom environment variables, you can use the values in the environment variables as a priority in your program. For example, you have set the port number to use the environment variable firstPORTthe value that the project member executes when developingPORT=8080 npm startcommand, you can customize the port number to 8080.

Issues encountered when using environment variables

The solution above can be used for most scenarios, but it does not solve the cross-platform and persistence issues of setting environment variables

Cross-platform

If you have a member of the Windows operating system in your project, perform npm run build (i.e. NODE_ENV=production webpack ) fails because Windows commands do not support setting environment variables in this way. Although it can be executed manually under Windows based on the build script content, set NODE_ENV=production webpack It destroys the original intent of the unified front-end engineering command, which requires the introduction of a library to address cross-platform set environment variables. If you use Cross-env, cross-env NODE_ENV=production webpack You can work across platforms as long as you rewrite the build script in Package.json.

Persistence of

as the scale increases, the number of project custom environment variables can be more and more. For example, after the deployment of static resources to use a CDN, the project production model needs to provide an environment variable to support the custom Webpack publicpath field, or for example, some members do not run the API server in the machine, but run in the virtual machine or another computer, The project development model needs to provide two environment variables to support custom API server addresses and port numbers ... It is possible for a member to execute such a long command each time it is developed: PORT=8080 API_SERVER=192.168.100.100 API_PORT=9000 npm start Therefore, a tool that can persist environment variables, such as using dotenv or env-cmd, is required. In Env-cmd, for example, simply create a. env.local file (not included in version management) and write to:

Node_env=development
port=8080
api_server=192.168.100.100
api_port=9000

overwrite the start command in Package.json (similar to the build command) to env-cmd --fallback ./.env.local webpack you can solve the problem of too many custom environment variables per manual input.

A truly useful environment variable management tool

There are many tools for managing environment variables, and the following is a simple analysis of the advantages and disadvantages of common tools dotenv, Cross-env, and Env-cmd:

• Dotenv can solve cross-platform and persistent problems, but with limited usage scenarios, only node projects, and strong coupling to project code, need to execute triggers manually after node code is run

• CROSS-ENV supports custom environment variables at the command line. The problem is also obvious and does not solve the persistence of custom environment variables in large projects

• Env-cmd also solves cross-platform and persistent problems, supports defining default environment variables, and does not support customizing environment variables on the command line

in fact, NPM itself provides functionality similar to setting project environment variables. Use the custom port number above as an example, or you can execute it under the project directorynpm config set project-name:PORT 8080(Project-name is the project name), executenpm startcan be passed in the code after theprocess.env.npm_package_config_PORTgets to 8080. You can also set the Config field in Package.json to{"PORT": 8000}, to specifynpm_package_config_PORTthe default value. The biggest advantage of managing environment variables using the NPM config feature is native support, and the default environment variables placed in the Package.json config field are also very easy to see. Unfortunately, the variable name is preceded by a lengthynpm_package_config_The script must be executed from the Package.json scripts field (that is, run NPM run Your_script_name), and all projects share a profile (. NPMRC, which is by default in the user directory), which is inconvenient for manual editing and viewing.

Therefore, a useful front-end environment variable management tool should have the following features:

• Support for command line setting environment variables

• Cross-platform

• Persistence, it is best to provide a command-line tool to set local environment variables

• Support for setting default environment variables

• support for obtaining the environment variables provided by NPM ( npm_package_* and the npm_config_* )

For this reason, an environment variable management tool was created: Fuck-env, "spoof environment variable", supports all of the above features.

FUCK-ENV Installation and use

NPM Install Fuck-env

If you have a project containing Package.json and main.js two files, the file code is as follows:

Package.json

{
  "Name": "Fuck-env-demo",
  "Config": {
    "PORT": 8000,
    "App_name": "$NPM _package_name"
  },
  "Scripts": {
    "Start": "Fuck-env node Main.js"
  },
  "Dependencies": {
    "Fuck-env": "*"
  }
}

Main.js

Console.log (Process.env.PORT)     //8080
Console.log (Process.env.APP_NAME)//Fuck-env-demo

Execution fuck-env PORT=8080 npm start , output "8080" and "Fuck-env-demo", whether in Windows or POSIX (MacOS, Linux, etc.) systems.

If a member wants to persist a custom port number locally, you can create a new. env file (This file must be added to the. Gitignore, not included in version management, in the form of a simple key-value pair for the class. ini file).

. env

port=8080

just do npm start it later can be. In addition, FUCK-ENV provides another command-line tool: Fuck, which allows you to quickly set local environment variables. For example, if a member wishes to use port 9000, it can be executed under the project root directory fuck set PORT 9000 (Global installation of fuck-env), and the contents of the. env file in the project directory will change to "port=9000", using fuck Commands are very handy when there are many environment variables.

When there are too many environment variables, all of the config fields that are placed Package.json will appear bloated. FUCK-ENV supports the unified management of default environment variables by simply moving all environment variables under the Config field to the Default.env file (counted in the repository).

For more examples, please refer to here

Fuck-env is committed to solve the user management environment variables encountered in various problems, is still in Beta stage, the future will be added more humanized design. If you have any ideas, you are welcome to make valuable suggestions for the project.

Original address: Https://lon.im/post/use-envir ...

This article mainly analyzes the problems encountered when using environment variables to manage front-end projects, and describes common tools to give solutions.

How to use environment variables

when building a webpack front-end project (or any Node-based project, this article takes the Webpack project as an example), it is generally necessary to provide two modes of operation: Development mode and production mode. It is common practice to set environment variables before executing commandsNODE_ENVto beproduction, such as executingNODE_ENV=production webpackcommand, and then in JavaScript code through theprocess.env.NODE_ENV === 'production'to judge is the production mode, otherwise the development mode. Different operations can be performed by distinguishing between different modes, such as starting the development server in development mode and forwarding the API, or compressing the merge code in production mode. In order to better unify the front-end Engineering command, you can add the command to start the development mode and production mode into the scripts field of the Package.json file, and then only need to executenpm startornpm run buildcan be. Defining environment variables is a good way to resolve the need to perform variance operations in your project. If you want to support member custom environment variables, you can use the values in the environment variables as a priority in your program. For example, you have set the port number to use the environment variable firstPORTthe value that the project member executes when developingPORT=8080 npm startcommand, you can customize the port number to 8080.

Issues encountered when using environment variables

The solution above can be used for most scenarios, but it does not solve the cross-platform and persistence issues of setting environment variables

Cross-platform

If you have a member of the Windows operating system in your project, perform npm run build (i.e. NODE_ENV=production webpack ) fails because Windows commands do not support setting environment variables in this way. Although it can be executed manually under Windows based on the build script content, set NODE_ENV=production webpack It destroys the original intent of the unified front-end engineering command, which requires the introduction of a library to address cross-platform set environment variables. If you use Cross-env, cross-env NODE_ENV=production webpack You can work across platforms as long as you rewrite the build script in Package.json.

Persistence of

as the scale increases, the number of project custom environment variables can be more and more. For example, after the deployment of static resources to use a CDN, the project production model needs to provide an environment variable to support the custom Webpack publicpath field, or for example, some members do not run the API server in the machine, but run in the virtual machine or another computer, The project development model needs to provide two environment variables to support custom API server addresses and port numbers ... It is possible for a member to execute such a long command each time it is developed: PORT=8080 API_SERVER=192.168.100.100 API_PORT=9000 npm start Therefore, a tool that can persist environment variables, such as using dotenv or env-cmd, is required. In Env-cmd, for example, simply create a. env.local file (not included in version management) and write to:

Node_env=development
port=8080
api_server=192.168.100.100
api_port=9000

overwrite the start command in Package.json (similar to the build command) to env-cmd --fallback ./.env.local webpack you can solve the problem of too many custom environment variables per manual input.

A truly useful environment variable management tool

There are many tools for managing environment variables, and the following is a simple analysis of the advantages and disadvantages of common tools dotenv, Cross-env, and Env-cmd:

• Dotenv can solve cross-platform and persistent problems, but with limited usage scenarios, only node projects, and strong coupling to project code, need to execute triggers manually after node code is run

• CROSS-ENV supports custom environment variables at the command line. The problem is also obvious and does not solve the persistence of custom environment variables in large projects

• Env-cmd also solves cross-platform and persistent problems, supports defining default environment variables, and does not support customizing environment variables on the command line

in fact, NPM itself provides functionality similar to setting project environment variables. Use the custom port number above as an example, or you can execute it under the project directorynpm config set project-name:PORT 8080(Project-name is the project name), executenpm startcan be passed in the code after theprocess.env.npm_package_config_PORTgets to 8080. You can also set the Config field in Package.json to{"PORT": 8000}, to specifynpm_package_config_PORTthe default value. The biggest advantage of managing environment variables using the NPM config feature is native support, and the default environment variables placed in the Package.json config field are also very easy to see. Unfortunately, the variable name is preceded by a lengthynpm_package_config_The script must be executed from the Package.json scripts field (that is, run NPM run Your_script_name), and all projects share a profile (. NPMRC, which is by default in the user directory), which is inconvenient for manual editing and viewing.

Therefore, a useful front-end environment variable management tool should have the following features:

• Support for command line setting environment variables

• Cross-platform

• Persistence, it is best to provide a command-line tool to set local environment variables

• Support for setting default environment variables

• support for obtaining the environment variables provided by NPM ( npm_package_* and the npm_config_* )

For this reason, an environment variable management tool was created: Fuck-env, "spoof environment variable", supports all of the above features.

FUCK-ENV Installation and use

NPM Install Fuck-env

If you have a project containing Package.json and main.js two files, the file code is as follows:

Package.json

{
  "Name": "Fuck-env-demo",
  "Config": {
    "PORT": 8000,
    "App_name": "$NPM _package_name"
  },
  "Scripts": {
    "Start": "Fuck-env node Main.js"
  },
  "Dependencies": {
    "Fuck-env": "*"
  }
}

Main.js

Console.log (Process.env.PORT)     //8080
Console.log (Process.env.APP_NAME)//Fuck-env-demo

Execution fuck-env PORT=8080 npm start , output "8080" and "Fuck-env-demo", whether in Windows or POSIX (MacOS, Linux, etc.) systems.

If a member wants to persist a custom port number locally, you can create a new. env file (This file must be added to the. Gitignore, not included in version management, in the form of a simple key-value pair for the class. ini file).

. env

port=8080

just do npm start it later can be. In addition, FUCK-ENV provides another command-line tool: Fuck, which allows you to quickly set local environment variables. For example, if a member wishes to use port 9000, it can be executed under the project root directory fuck set PORT 9000 (Global installation of fuck-env), and the contents of the. env file in the project directory will change to "port=9000", using fuck Commands are very handy when there are many environment variables.

When there are too many environment variables, all of the config fields that are placed Package.json will appear bloated. FUCK-ENV supports the unified management of default environment variables by simply moving all environment variables under the Config field to the Default.env file (counted in the repository).

The above content is how to better manage the front-end environment variable method, I hope to be helpful to everyone.

Related recommendations:

What is an environment variable? The role of environmental variables

Sharing environment variables and file lookup instances

Ways to set up and view environment variables in Linux