How to set some environment variables from within package.json to be used with npm start like commands?
Here's what I currently have in my package.json:
{
...
"scripts": {
"help": "tagove help",
"start": "tagove start"
}
...
}
I want to set environment variables (like NODE_ENV) in the start script while still being able to start the app with just one command, npm start.
Set the environment variable in the script command:
...
"scripts": {
"start": "node app.js",
"test": "NODE_ENV=test mocha --reporter spec"
},
...
Then use process.env.NODE_ENV in your app.
Note: This is for Mac & Linux only. For Windows refer to the comments.
Just use NPM package cross-env. Super easy. Works on Windows, Linux, and all environments. Notice that you don't use && to move to the next task. You just set the env and then start the next task. Credit to #mikekidder for the suggestion in one of the comments here.
From documentation:
{
"scripts": {
"build": "cross-env NODE_ENV=production OTHERFLAG=myValue webpack --config build/webpack.config.js"
}
}
Notice that if you want to set multiple global vars, you just state them in succession, followed by your command to be executed.
Ultimately, the command that is executed (using spawn) is:
webpack --config build/webpack.config.js
The NODE_ENV environment variable will be set by cross-env
I just wanted to add my two cents here for future Node-explorers. On my Ubuntu 14.04 the NODE_ENV=test didn't work, I had to use export NODE_ENV=test after which NODE_ENV=test started working too, weird.
On Windows as have been said you have to use set NODE_ENV=test but for a cross-platform solution the cross-env library didn't seem to do the trick and do you really need a library to do this:
export NODE_ENV=test || set NODE_ENV=test&& yadda yadda
The vertical bars are needed as otherwise Windows would crash on the unrecognized export NODE_ENV command. I don't know about the trailing space, but just to be sure I removed them too.
Because I often find myself working with multiple environment variables, I find it useful to keep them in a separate .env file (make sure to ignore this from your source control). Then (in Linux) prepend export $(cat .env | xargs) && in your script command before starting your app.
Example .env file:
VAR_A=Hello World
VAR_B=format the .env file like this with new vars separated by a line break
Example index.js:
console.log('Test', process.env.VAR_A, process.env.VAR_B);
Example package.json:
{
...
"scripts": {
"start": "node index.js",
"env-linux": "export $(cat .env | xargs) && env",
"start-linux": "export $(cat .env | xargs) && npm start",
"env-windows": "(for /F \"tokens=*\" %i in (.env) do set %i)",
"start-windows": "(for /F \"tokens=*\" %i in (.env) do set %i) && npm start",
}
...
}
Unfortunately I can't seem to set the environment variables by calling a script from a script -- like "start-windows": "npm run env-windows && npm start" -- so there is some redundancy in the scripts.
For a test you can see the env variables by running npm run env-linux or npm run env-windows, and test that they make it into your app by running npm run start-linux or npm run start-windows.
Try this on Windows by replacing YOURENV:
{
...
"scripts": {
"help": "set NODE_ENV=YOURENV && tagove help",
"start": "set NODE_ENV=YOURENV && tagove start"
}
...
}
#luke's answer was almost the one I needed! Thanks.
As the selected answer is very straightforward (and correct), but old, I would like to offer an alternative for importing variables from a .env separate file when running your scripts and fixing some limitations to Luke's answer.
Try this:
::: .env file :::
# This way, you CAN use comments in your .env files
NODE_PATH="src/"
# You can also have extra/empty lines in it
SASS_PATH="node_modules:src/styles"
Then, in your package json, you will create a script that will set the variables and run it before the scripts you need them:
::: package.json :::
scripts: {
"set-env": "export $(cat .env | grep \"^[^#;]\" |xargs)",
"storybook": "npm run set-env && start-storybook -s public"
}
Some observations:
The regular expression in the grep'ed cat command will clear the comments and empty lines.
The && don't need to be "glued" to npm run set-env, as it would be required if you were setting the variables in the same command.
If you are using yarn, you may see a warning, you can either change it to yarn set-env or use npm run set-env --scripts-prepend-node-path && instead.
Different environments
Another advantage when using it is that you can have different environment variables.
scripts: {
"set-env:production": "export $(cat .production.env | grep \"^[^#;]\" |xargs)",
"set-env:development": "export $(cat .env | grep \"^[^#;]\" |xargs)",
}
Please, remember not to add .env files to your git repository when you have keys, passwords or sensitive/personal data in them!
UPDATE: This solution may break in npm v7 due to npm RFC 21
CAVEAT: no idea if this works with yarn
npm (and yarn) passes a lot of data from package.json into scripts as environment variables. Use npm run env to see them all. This is documented in https://docs.npmjs.com/misc/scripts#environment and is not only for "lifecycle" scripts like prepublish but also any script executed by npm run.
You can access these inside code (e.g. process.env.npm_package_config_port in JS) but they're already available to the shell running the scripts so you can also access them as $npm_... expansions in the "scripts" (unix syntax, might not work on windows?).
The "config" section seems intended for this use:
"name": "myproject",
...
"config": {
"port": "8010"
},
"scripts": {
"start": "node server.js $npm_package_config_port",
"test": "wait-on http://localhost:$npm_package_config_port/ && node test.js http://localhost:$npm_package_config_port/"
}
An important quality of these "config" fields is that users can override them without modifying package.json!
$ npm run start
> myproject#0.0.0 start /home/cben/mydir
> node server.js $npm_package_config_port
Serving on localhost:8010
$ npm config set myproject:port 8020
$ git diff package.json # no change!
$ cat ~/.npmrc
myproject:port=8020
$ npm run start
> myproject#0.0.0 start /home/cben/mydir
> node server.js $npm_package_config_port
Serving on localhost:8020
See npm config and yarn config docs.
It appears that yarn reads ~/.npmrc so npm config set affects both, but yarn config set writes to ~/.yarnrc, so only yarn will see it :-(
For a larger set of environment variables or when you want to reuse them you can use env-cmd.
As a plus, the .env file would also work with direnv.
./.env file:
# This is a comment
ENV1=THANKS
ENV2=FOR ALL
ENV3=THE FISH
./package.json:
{
"scripts": {
"test": "env-cmd mocha -R spec"
}
}
This will work in Windows console:
"scripts": {
"setAndStart": "set TMP=test&& node index.js",
"otherScriptCmd": "echo %TMP%"
}
npm run aaa
output:
test
See this answer for details.
suddenly i found that actionhero is using following code, that solved my problem by just passing --NODE_ENV=production in start script command option.
if(argv['NODE_ENV'] != null){
api.env = argv['NODE_ENV'];
} else if(process.env.NODE_ENV != null){
api.env = process.env.NODE_ENV;
}
i would really appreciate to accept answer of someone else who know more better way to set environment variables in package.json or init script or something like, where app bootstrapped by someone else.
use git bash in windows. Git Bash processes commands differently than cmd.
Most Windows command prompts will choke when you set environment variables with NODE_ENV=production like that. (The exception is Bash on Windows, which uses native Bash.) Similarly, there's a difference in how windows and POSIX commands utilize environment variables. With POSIX, you use: $ENV_VAR and on windows you use %ENV_VAR%. - cross-env doc
{
...
"scripts": {
"help": "tagove help",
"start": "env NODE_ENV=production tagove start"
}
...
}
use dotenv package to declare the env variables
For single environment variable
"scripts": {
"start": "set NODE_ENV=production&& node server.js"
}
For multiple environment variables
"scripts": {
"start": "set NODE_ENV=production&& set PORT=8000&& node server.js"
}
When the NODE_ENV environment variable is set to 'production' all devDependencies in your package.json file will be completely ignored when running npm install. You can also enforce this with a --production flag:
npm install --production
For setting NODE_ENV you can use any of these methods
method 1: set NODE_ENV for all node apps
Windows :
set NODE_ENV=production
Linux, macOS or other unix based system :
export NODE_ENV=production
This sets NODE_ENV for current bash session thus any apps started after this statement will have NODE_ENV set to production.
method 2: set NODE_ENV for current app
NODE_ENV=production node app.js
This will set NODE_ENV for the current app only. This helps when we want to test our apps on different environments.
method 3: create .env file and use it
This uses the idea explained here. Refer this post for more detailed explanation.
Basically, you create a .env file and run some bash scripts to set them on the environment.
To avoid writing a bash script, the env-cmd package can be used to load the environment variables defined in the .env file.
env-cmd .env node app.js
method 4: Use cross-env package
This package allows environment variables to be set in one way for every platform.
After installing it with npm, you can just add it to your deployment script in package.json as follows:
"build:deploy": "cross-env NODE_ENV=production webpack"
{
...
"scripts": {
"start": "ENV NODE_ENV=production someapp --options"
}
...
}
Most elegant and portable solution:
package.json:
"scripts": {
"serve": "export NODE_PRESERVE_SYMLINKS_MAIN=1 && vue-cli-service serve"
},
Under windows create export.cmd and put it somewhere to your %PATH%:
#echo off
set %*
If you:
Are currently using Windows;
Have git bash installed;
Don't want to use set ENV in your package.json which makes it only runnable for Windows dev machines;
Then you can set the script shell of node from cmd to git bash and write linux-style env setting statements in package.json for it to work on both Windows/Linux/Mac.
$ npm config set script-shell "C:\\Program Files\\git\\bin\\bash.exe"
Although not directly answering the question I´d like to share an idea on top of the other answers. From what I got each of these would offer some level of complexity to achieve cross platform independency.
On my scenario all I wanted, originally, to set a variable to control whether or not to secure the server with JWT authentication (for development purposes)
After reading the answers I decided simply to create 2 different files, with authentication turned on and off respectively.
"scripts": {
"dev": "nodemon --debug index_auth.js",
"devna": "nodemon --debug index_no_auth.js",
}
The files are simply wrappers that call the original index.js file (which I renamed to appbootstrapper.js):
//index_no_auth.js authentication turned off
const bootstrapper = require('./appbootstrapper');
bootstrapper(false);
//index_auth.js authentication turned on
const bootstrapper = require('./appbootstrapper');
bootstrapper(true);
class AppBootStrapper {
init(useauth) {
//real initialization
}
}
Perhaps this can help someone else
Running a node.js script from package.json with multiple environment variables:
package.json file:
"scripts": {
"do-nothing": "set NODE_ENV=prod4 && set LOCAL_RUN=true && node ./x.js",
},
x.js file can be as:
let env = process.env.NODE_ENV;
let isLocal = process.env.LOCAL_RUN;
console.log("ENV" , env);
console.log("isLocal", isLocal);
You should not set ENV variables in package.json. actionhero uses NODE_ENV to allow you to change configuration options which are loaded from the files in ./config. Check out the redis config file, and see how NODE_ENV is uses to change database options in NODE_ENV=test
If you want to use other ENV variables to set things (perhaps the HTTP port), you still don't need to change anything in package.json. For example, if you set PORT=1234 in ENV and want to use that as the HTTP port in NODE_ENV=production, just reference that in the relevant config file, IE:
# in config/servers/web.js
exports.production = {
servers: {
web: function(api){
return {
port: process.env.PORT
}
}
}
}
In addition to use of cross-env as documented above, for setting a few environment variables within a package.json 'run script', if your script involves running NodeJS, then you can set Node to pre-require dotenv/config:
{
scripts: {
"eg:js": "node -r dotenv/config your-script.js",
"eg:ts": "ts-node -r dotenv/config your-script.ts",
"test": "ts-node -r dotenv/config -C 'console.log(process.env.PATH)'",
}
}
This will cause your node interpreter to require dotenv/config, which will itself read the .env file in the present working directory from which node was called.
The .env format is lax or liberal:
# Comments are permitted
FOO=123
BAR=${FOO}
BAZ=Basingstoke Round About
#Blank lines are no problem
Note : In order to set multiple environment variable, script should goes like this
"scripts": {
"start": "set NODE_ENV=production&& set MONGO_USER=your_DB_USER_NAME&& set MONGO_PASSWORD=DB_PASSWORD&& set MONGO_DEFAULT_DATABASE=DB_NAME&& node app.js",
},
I'm trying to install/use this cypress plugin https://github.com/bjowes/cypress-ntlm-auth for my automation tests so I can login to an application that uses ntlm authenticator, but I cannot use npm install --save-dev cypress-ntlm-auth command cause of corporate security policies.
I've downloaded the zip repo release of this plugin and also have cypress installed, but I don't know the exact steps to do this without npm install.
I've tried adding this in the cypress/plugins/index.js file:
const ntlmAuth = require('cypress-ntlm-auth-3.2.5/test/e2e/cypress/plugins/index.ts');
module.exports = (on, config) => {
config = ntlmAuth.initNtlmAuth(config);
return config;
}
and also added this is cypress/support/index.js file:
import "cypress-ntlm-auth-master/src/commands"
but I have the following error while trying to open cypress: Error: Cannot find module 'cypress-ntlm-auth-3.2.5/test/e2e/cypress/plugins/index.ts' (the index.ts file is in the mentioned location)
I think I might be missing some installing/configuration steps. Can someone help?
Assuming you unzipped to node_modules, this is the difference between an npm install (left) and a zip (right).
Try hacking this
rename the unzipped src to dist
add http-mitm-proxy
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case 'uname' in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
"$basedir/node" "$basedir/../../../http-mitm-proxy/bin/mitm-proxy.js" "$#"
ret=$?
else
node "$basedir/../../../http-mitm-proxy/bin/mitm-proxy.js" "$#"
ret=$?
fi
exit $ret
add http-mitm-proxy.cmd
#IF EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" "%~dp0\..\..\..\http-mitm-proxy\bin\mitm-proxy.js" %*
) ELSE (
#SETLOCAL
#SET PATHEXT=%PATHEXT:;.JS;=;%
node "%~dp0\..\..\..\http-mitm-proxy\bin\mitm-proxy.js" %*
)
These two files are also found in /node_modules/.bin with the file names cypress-ntlm and cypress-ntlm.cmd, which may be the critical bit, so copy them there as well.
I think using yarn might help : yarn add cypress-ntlm-auth
Install yarn by : npm install yarn -g
I have a scripts folder in which many individual scripts inside seperate folder, I would like to build each separately via passing the script name as parameter.
I have set up rollup in package.json like "watch": "rollup --watch --config rollup.config.js"
I would like to pass parameter from cli like npm run watch script_name=abc_script
It can be accessible in rollup.config.js via process.argv
But getting this error
rollup v1.23.1
bundles abc_script → dist/bundle.js
[!] Error: Could not resolve entry module
Everything seems fine without npm cli parameter.
Rollup have --environment variable but it's bit long to use npm run watch -- --environment script:script_name
Is there any way to shorten this?
Thanks in advance.
While the following answer doesn't directly address OP's need (to pass variables in via command line), it does address their desire for brevity ("--environment variable but it's bit long to use")
Create a .env file in your project's root directory and fill it with VAR_NAME=value on each line
NODE_ENV=development
SECRET_KEY=ahuehueheueheueheu
DON'T COMMIT THAT FILE. Instead, add .env to your .gitignore.
Next install dotenv node package
npm i -D dotenv
yarn add -D dotenv
And finally put this at the very top of your rollup.config.js
import dotenv from 'dotenv';
dotenv.config();
You can pass arguments which will be caught by process.argv like this
npm run watch -- some_arg
In your program, you will get an array in process.argv in this the last value will be the value passed to the program.
Alternatively, you can pass environment variables to the command - it's much easier to process than command-line arguments.
Cli usage:
minify=on ./node_modules/.bin/rollup -c
package.json script:
{
...
scripts: {
...
"build-production": "minify=on rollup -c"
}
}
rollup.config.js
const enableMinification = process.env.minify === 'on'
npm run watch -- --environment script=script_name worked for me, So I can access script_name via process.env in rollup config
I am building a package that uses an external command tool named plop js. In my package.json I want to add a binary that references to an index.js file.
"scripts":{
"plop": "plop"
},
"bin": {
"my-command": "index.js"
},
There is a way to run the plop script from my package in the index.js file?
My goal is to run this script when the user writes my-command in the terminal. (and use the local plop, I want this to be transparent to the consumer)
The reason you can't directly require and use plop is that it is a CLI. As a CLI, it does not export anything but uses process.argv as its input. So all you really need to do is alter process.argv in your script before requireing plop.
process.argv.push('--version');
require('plop');
You could then use the built in --plopfile argument to point to a specific file that you'd like to run.
I just have the same issue and found this code work:
#!/usr/bin/env node
process.argv.push('--plopfile', __dirname + '/plopfile.js');
require('plop');
Since "plop": "^2.7.3",
I found the above not work any more and from https://github.com/plopjs/plop/issues/78
I saw the new solution
#!/usr/bin/env node
const args = process.argv.slice(2);
const {Plop, run} = require('plop');
const argv = require('minimist')(args);
Plop.launch({
cwd: argv.cwd,
configPath: argv.plopfile, // changed to `${process.cwd()}/plopfile.js` in my case
require: argv.require,
completion: argv.completion
}, run);
npm's scripts are (except of start) always being run like npm run plop.
Usually you define a start command which is normally run like npm start and is known by everyone. You can also chain commands there (if you need to run multiple).
Assuming that you want to run plop as first command: If you type npm start, it will execute plop and afterwards node index.js
"scripts":{
"start": "plop && node index.js"
},
If you want to run something just **once* after npm install, put it into "postinstall" : "plop"
In ruby when using rbenv you can make a .ruby-version file and put it in the local directory. https://gist.github.com/fnichol/1912050
I'm looking for something similar to this using NVM?
Question:
Is there a property to set in package.json or a file to create that will set the default version of node of a project?
You can do this with a combination of NVM, dotfiles in your project directory, and a little tool called direnv which allows you to load in environment variables on a per-directory basis.
http://direnv.net/
Install NVM and direnv, and then cd to the directory you want to change Node versions in.
Add a file called .nvmrc in that directory, containing just the version number of the Node version you want to auto-switch to, e.g.,:
6.2.2
Then add an environment configuration file called .envrc to your directory, containing this script:
nvmrc=~/.nvm/nvm.sh
if [ -e $nvmrc ]; then
source $nvmrc
nvm use
fi
PATH_add node_modules/.bin
If you now cd out of this directory, and then cd back in, direnv will kick in and you should be asked to add the directory to your direnv whitelist by typing direnv allow . at the prompt. Once whitelisted, direnv will auto-run that script whenever you enter this directory, setting your Node version to the version number in .nvmrc.
As a bonus, it will also add the node_modules directory to your PATH, so you can execute binaries from those directories without prepending the node_modules path.
There is now some native support for this built into direnv's stdlib. It's documented in their wiki, but the source is just as easy to read, or type direnv stdlib to find it).
$ node -v
v8.0.0
$ cat .node-version
4.3.2
$ cat .envrc
use node
$ export NODE_VERSIONS=~/.nvm/versions/node
$ export NODE_VERSION_PREFIX=v
$ direnv allow
direnv: loading ~/.config/direnv/direnvrc
direnv: loading .envrc
direnv: using node
direnv: Successfully loaded NodeJS v4.3.2 (via .node-version), from prefix (~/.nvm/versions/node/v4.3.2)
direnv: export +CPATH +LD_LIBRARY_PATH +LIBRARY_PATH +PKG_CONFIG_PATH ~MANPATH ~PATH
$ node -v
v4.3.2
$ direnv deny
direnv: error .envrc is blocked. Run `direnv allow` to approve its content.
$ node -v
v8.0.0
If you want node_modules/.bin in your path, just add the line layout node to your .envrc (the source is also in direnv stdlib output).
Here's how I do it, generally similar to Ross Shannon's answer, with a few differences:
You can specify the Node version in just the package.json, without requiring an .nvmrc file
You can also specify the Node version directly in the .envrc, again without an .nvmrc file
I don't add node_modules/.bin to the PATH, but if that's your preferred behavior, just add PATH_add node_modules/.bin to the use_nvm function.
For me, supporting Node version selection from package.json rather than .nvmrc was important because I didn't want to worry about keeping two files in sync (especially on a project with multiple collaborators). That said, this solution still works with .nvmrc.
This solution requires direnv, nvm and optionally (if you want to be able to select the Node version from package.json) jq.
In ~/.config/direnv/direnvrc file, add the following:
# To use:
# 1) Node version specified in package.json, in .envrc add:
# use nvm package.json
# This requires that package.json contains something like
# "engines": {
# "node": ">=6.9.2"
# },
#
# 2) Node version specified in .envrc add:
# use nvm 6.9.2
#
# 3) Node version specified in .nvmrc, in .envrc add:
# use nvm
use_nvm() {
local node_version=$1
if [[ $node_version = "package.json" ]]; then
if has jq; then
node_version=$(jq --raw-output .engines.node package.json | tr -d "<=> ")
else
echo "Parsing package.json for node version to use with direnv requires jq"
fi
fi
nvm_sh=~/.nvm/nvm.sh
if [[ -e $nvm_sh ]]; then
source $nvm_sh
nvm use $node_version
fi
}
In your project directory, add an .envrc file that calls use nvm, e.g.:
use nvm package.json
However, I prefer something like the following for my .envrc:
if declare -Ff use_nvm >/dev/null; then
use nvm package.json
fi
for shared projects with a shared .envrc so that collaborators who don't have use nvm defined don't get an error.
Now, when you enter your project directory, your desired Node version will be automatically used (the first time, you'll be prompted to whitelist your changes to .envrc with direnv allow).
Note: This solution does not switch the folder version automatically.
Other answers were not that helpful to me, and hence, this is the solution I followed:
Create a .nvmrc file and specify the node version you expect your app to run on.
touch .nvmrc
Open the file and specify the version, say 13.3.0
Post you define a version in .nvmrc, you can alternatively also define the engines in the package.json file, which will ensure that the version meets the requirements, if it doesn't, running npm install will fail.
"engineStrict": true,
"engines": {
"node": "13.3.0"
}
Below is the error you'll encounter if it fails to match the node version.
Lastly, to ensure that it switches to the right node version, you can either run the following command post navigating to the directory.
nvm use
And this will switch to the desired version, or you can add it to one of the script command in package.json like:
"scripts": {
/*
* here, the second command (nodemon server.js) will change base on the dev
* server you are using and the path where you've server.js
*/
"dev:app:run": "nvm use; nodemon server.js"
},
The above will switch the node version before it starts the server.