Security News
Input Validation Vulnerabilities Dominate MITRE's 2024 CWE Top 25 List
MITRE's 2024 CWE Top 25 highlights critical software vulnerabilities like XSS, SQL Injection, and CSRF, reflecting shifts due to a refined ranking methodology.
by-node-env
Advanced tools
Run package.json scripts by NODE_ENV.
Install with npm:
npm install by-node-env
Install with pnpm:
pnpm install by-node-env
Install with Yarn:
yarn add by-node-env
NODE_ENV
from process.env
.NODE_ENV
from .env file.NODE_ENV
to development
.process.env
for each NODE_ENV
.NODE_ENV
:
npm install
or pnpm install
or yarn install
.npm start
or pnpm start
or yarn start
.When developing a Node.js application in development
mode, we often use these different commands: npm run serve
, npm run watch
, npm run dev
, etc. In addition, we also set NODE_ENV=development
as an environment variable.
When deploying to production
, we often use these different commands: npm start
, npm build
, npm run prod
, etc. NODE_ENV=production
is a must-have environment variable in this case.
The package.json might look like this for those situations mentioned above:
{
"scripts": {
"watch": "webpack -d --watch",
"build": "webpack -p",
"dev": "nodemon src",
"prod": "node dist",
"serve": "npm run watch & npm run dev",
"start": "npm build && npm run prod"
}
}
Working on multiple projects with different commands can be very confusing and forgetting, especially under heavy cognitive load. As a result, we spend a lot of time consulting the README or the scripts field in package.json.
{
"scripts": {
"build": "by-node-env",
"build:development": "webpack -d --watch",
"build:production": "webpack -p",
"start": "by-node-env",
"start:development": "npm build & nodemon src",
"start:production": "npm build && node dist"
}
}
npm build
and npm start
have long been the de facto commands to build and start a Node.js application, respectively.
Besides that, NODE_ENV
should always be explicitly set as an environment variable for best practice. A lot of popular frameworks expect NODE_ENV
to be set as well.
Why not combine both, so that when NODE_ENV=production
, executing npm start
will spawn npm run start:production
. Similarly, when NODE_ENV=development
, executing npm start
will spawn npm run start:development
.
Arbitrary NODE_ENV
and scripts work too, refer to more examples below.
The priority order of resolving NODE_ENV
is as follows:
development
(default).The .env file, if present, must be located in the root directory of your project, where package.json lie.
The resolved NODE_ENV
is available as process.env.NODE_ENV
in your application at runtime.
{
"scripts": {
"start": "by-node-env", // 1
"start:development": "ts-node src", // 2a
"start:production": "ts-node-dev src" // 2b
}
}
npm start
: 1 :arrow_right: 2aNODE_ENV=development npm start
: 1 :arrow_right: 2aNODE_ENV=production npm start
: 1 :arrow_right: 2bNODE_ENV=production
{
"scripts": {
"start": "by-node-env", // 1
"start:development": "ts-node src", // 2a
"start:production": "ts-node-dev src" // 2b
}
}
npm start
: 1 :arrow_right: 2bNODE_ENV=development npm start
: 1 :arrow_right: 2aNODE_ENV=production npm start
: 1 :arrow_right: 2b{
"scripts": {
// If NODE_ENV is missing, defaults to "development".
"build": "by-node-env",
"build:development": "webpack -d --watch",
"build:production": "webpack -p",
"build:staging": "webpack -p",
// Deployment will not work unless NODE_ENV=production is explicitly set.
"deploy": "by-node-env",
"predeploy:production": "docker build -t ${DOCKER_USER}/${DOCKER_PROJECT} .",
"deploy:production": "docker push ${DOCKER_USER}/${DOCKER_PROJECT}",
// "npm start" is _the_ command to start the server across all environments.
"start": "by-node-env",
"start:development": "npm run build:development",
"prestart:production": "npm run build",
"start:production": "start-cluster build/server/server.js",
"prestart:staging": "npm run build",
"start:staging": "start-cluster build/server/server.js",
// Explicitly set NODE_ENV, which is helpful in CI.
"test": "NODE_ENV=test by-node-env",
"test:test": "mocha"
}
}
Encounter bugs or having new suggestions?
Issues, comments, and PRs are always welcomed!
FAQs
Run package.json scripts by NODE_ENV.
We found that by-node-env demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
MITRE's 2024 CWE Top 25 highlights critical software vulnerabilities like XSS, SQL Injection, and CSRF, reflecting shifts due to a refined ranking methodology.
Security News
In this segment of the Risky Business podcast, Feross Aboukhadijeh and Patrick Gray discuss the challenges of tracking malware discovered in open source softare.
Research
Security News
A threat actor's playbook for exploiting the npm ecosystem was exposed on the dark web, detailing how to build a blockchain-powered botnet.