I have the below scripts in my package.json:
"scripts": {
"vumper": "node node_modules/vumper/index.js",
"format": "prettier --single-quote -width=80 --write package.json"
},
The 'vumper' package takes in a command line argument (such as 'dv'). What I would like to be able to do is have a command that runs both of these in succession.
Essentially, I would like to be able to run:
npm run vumber dv
and then
npm run format
but in one command, something like
npm run my-build dv
which would run both of the above commands, correctly accepting the command line argument 'dv' and passing it to the first npm run vumper. Is this possible?
Short Answer:
Essentially, what you're wanting is to have an npm-script something like this, whereby <arg-here> is provide via the CLI;
...
"scripts": {
"my-build": "npm run vumper <arg-here> && npm run format",
...
},
...
However, unfortunately npm does not have a built-in feature to achieve this.
The special npm option --, (refer to the end of Solution 1 below for further info about this option), can only be used to pass an argument to the END of a script but NOT into the MIDDLE. So, if your two commands were in the opposite order, the -- option could be used like this:
...
"scripts": {
"my-build": "npm run format && npm run vumper --",
...
},
...
To overcome the limitation of there being no built-in feature to pass an argument into the MIDDLE of a script consider the following solutions:
For a Bash only solution refer to the "Solution 1" section.
If cross platform support is required then follow the solution described in the "Solution 2" section.
Solution 1 - Bash (MacOS/Linux/ etc..):
Configure your my-build script in the scripts section of package.json to invoke a Bash shell function, as shown below:
package.json
...
"scripts": {
"my-build": "func() { npm run vumper \"$1\" && npm run format; }; func",
"vumper": "node node_modules/vumper/index.js",
"format": "prettier --single-quote -width=80 --write package.json"
},
...
Explanation:
The Bash function named func does the following:
Firstly runs npm run vumper <arg>. Whereby <arg> will be the shell argument passed via the CLI. It is referenced in the script using $1 (i.e. the first positional parameter/argument).
Subsequently it runs the script named format via the command npm run format.
These two npm run commands are chained using the && operator, so the second npm run format command will only run if the initial npm run vumper <arg> command completes successfully (i.e. returns a 0 exit code).
Running my-build script:
To invoke my-build via your CLI you'll need to run:
npm run my-build -- dv
Note:
In this instance the trailing dv part is the argument that will be passed to your vumper script.
The special option -- must be specified before the argument. The docs describe the -- option as:
... The special option -- is used by getopt to delimit the end of the options. npm will pass all the arguments after the -- directly to your script: ... The arguments will only be passed to the script specified after npm run and not to any pre or post script.
Solution 2 - Cross-platform:
For a cross-platform solution, (one which works successfully with Bash, Windows Command Prompt / cmd.exe, and PowerShell etc..), you'll need to utilize a nodejs helper script as follows.
run.js
Let's name the nodejs script run.js and save it in the projects root directory, at the same level as package.json.
const execSync = require('child_process').execSync;
const arg = process.argv[2] || 'dv'; // Default value `dv` if no args provided via CLI.
execSync('npm run vumper ' + arg, {stdio:[0, 1, 2]});
execSync('npm run format', {stdio:[0, 1, 2]});
package.json
Configure your my-build script to invoke run.js as follows:
...
"scripts": {
"my-build": "node run",
"vumper": "node node_modules/vumper/index.js",
"format": "prettier --single-quote -width=80 --write package.json"
},
...
Running my-build script:
As per Solution 1, to invoke my-build via your CLI you'll need to run:
npm run my-build -- dv
Explanation:
run.js utilizes process.argv to obtain the argument passed via the CLI (e.g. dv). If no argument is provided when running npm run my-build the default value, (i.e. dv), is passed to the vumper npm-script.
run.js also utilizes child_process.execSync(...) to shell-out/invoke the two npm run commands.
Npm now has a built-in option to pass cli arguments directly to scripts.
The cli arguments are stored in environmenet variables with prefix npm_config_<flagname>, and they required a very strict syntax, with the form --<flagname>=<flagvalue>.
Example:
"my-build": "npm run vumper %npm_config_myflag% && npm run format",
In the terminal, run npm run my-build --myflag=my_value to execute npm run vumper my_value && npm run format.
Note:
To refer the environment variable in the npm script, you have to use the platform specific syntax, ie %npm_config_myflag% in Windows or $npm_config_myflag in Linux.
UPDATE:
To avoid risks of conflict with the npm_config variables used to configure npm itself, just prefix your arguments with a unique prefix, such as the name of your app.
The potential conflict is a very common problem, which applies in many contexts: any application could use environment variables already used by other applications; for this reason, the environment variables are usually prefixed with the name of the application (eg NVM_HOME, JAVA_HOME). But this potential conflict is not a good reason to avoid using environment variables. The same in my opinion applies to npm params / npm_config env vars. The doc does not say anything about the risk of conflicts, implying I guess they should be managed as usual.
My preferred method is by using environment variables:
{
"scripts": {
"ncc-build": "ncc build $ACTION/src/index.ts -o $ACTION/dist",
"build:pr-changelog": "ACTION=pr-changelog npm run ncc-build",
}
}
It should work in UNIX systems. I'm not sure about windows platfrom compatibility though.
a different approach for doing this - to reach super deep into you dependency chain:
npm scripts section:
"test:local": "cross-env-shell UPDATE_BASELINE=false UPDATE_MODULE=%npm_config_vizdifsingle% run-p koa:ci wdio:local",
"test:remote": "cross-env-shell UPDATE_BASELINE=false UPDATE_MODULE=%npm_config_vizdifsingle% run-p localtunnel:start koa:ci wdio:remote"
by using crossenv and npm's value placement you can pass args to env.args
like this:
npm run test:local --vizdifsingle=some,value,or,values
it will be available to you in
process.env.npm_config_update_module
Related
I am using an NPM run task in Azure Devops Pipelines. I would like to pass an Azure Predefined Variable into my package.json.
eg: npm run cypresstask
So that I can then pass this as a parameter for 'cypress run --ci-build-id '
Answering my own question:
NPM Run Task command:
run cypress:ci --azbuildid=$(Build.BuildNumber)
then within package.json you can provide it as
cypress run --ci-build-id $npm_config_azbuildid
So you set params with the --. Provide predefined variables using $() and access them within package.json using $npm_config_
In your package.json file you can write your commands inside scripts:
"scripts": {
"test": "cypress run --ci-build-id"
}
And in your yml file you can just use:
npm test
I'm starting to play around with Snowpack. It takes a different approach from Webpack by bundling individual packages right after they're installed.
The "issue" is, when I install a package I have to first run npm install --save my-package and then I have to manually pack it with npx snowpack. The Snowpack docs mention that I can include a prepare script that would snowpack everything after running npm install but that doesn't apply to individual packages, just on a generic npm install of all dependencies in my package.json. As far as I can tell, this is the case for all npm hooks mentioned in the npm docs.
Is there any way I can automatically run a script whenever I install an individual package? The only way I can think of would be to overwrite the install script and add something to it. Are there any examples of this on GitHub or elsewhere?
Update: For clarification, I'd like to run npx snowpack every time I install a new package with --save but preferably not with --save-dev or without --save. This will never be different for any package. This will be specific to a certain repo/project, not global on my system.
It is not sufficient to run snowpack after simply running npm install as you would get by hooking into postinstall or release. Additionally, I want to make sure developers working on my project can use npm install --save newdep as they normally would and then snowpack will run. I do not want to require devs to use a custom named script.
Short answer: Unfortunately, npm does not provide any built-in feature(s) to meet your requirement.
Lifecycle hooks/scripts such as postinstall are invoked only when running the generic npm install command, and not when someone runs npm install --save <pkg_name> during the projects development phase.
Workaround: Consider customizing the logic of the npm install --save compound command by essentially overriding the npm command at the shell level.
The following solution, albeit a Bash one, describes how this custom logic can be actualized for a specific project(s). However, this solution is dependent on the following conditions:
Developers working on your project must have their the shell set to Bash when running the npm install --save compound command.
Developers working on your project will need to customize their Bash startup files, namely ~/.bashrc and possibly ~/.bash_profile.
The project directory, i.e. the project directory for which you want the custom logic to be effective, must contain a custom .bashrc file.
Bash Solution:
The following three steps are necessary to configure your project, and operating system(s), so that when a developer runs npm install --save <pkg_name> (or variations of it) the npx snowpack command is subsequently invoked.
Note: Points two and three (below) are the tasks developers need to carry out (once) to customize their Bash startup files.
The project specific .bashrc file:
Firstly create the following "project specific" .bashrc file in the root of your project directory, i.e. save it at the same level as where your projects package.json file resides:
/some/path/to/my-project/.bashrc
npm() {
local name_badge="\x1b[37;40mpostinstall\x1b[0m"
array_includes() {
local word=$1
shift
for el in "$#"; do [[ "$el" == "$word" ]] && return 0; done
}
log_warn_message() {
local cmd_name=$1 warn_badge warn_mssg
warn_badge="\x1b[30;43mWARN!\x1b[0m"
warn_mssg="${cmd_name} command not found. Cannot run npx snowpack."
echo -e "\n${name_badge} ${warn_badge} ${warn_mssg}" >&2
}
log_run_message() {
echo -e "\n${name_badge} Running pseudo postinstall hook."
}
if [[ $* == "install "* || $* == "i "* ]] && array_includes --save "$#"; then
# 1. Run the given `npm install --save ...` command.
command npm "$#"
# 2. Check whether the `npx` command exists globally.
command -v npx >/dev/null 2>&1 || {
log_warn_message npx
return 1
}
log_run_message
# 3. Run the pseudo "postinstall" command.
command npx snowpack
else
# Run all other `npm` commands as per normal.
command npm "$#"
fi
}
Note: For a better understanding of what this file does refer to the "Explanation" section below.
The ~/.bashrc file:
To make the custom logic, i.e. the npm function in the aforementioned .bashrc file, effective, it's necessary to configure Bash to read the aforementioned "project specific" .bashrc file. To configure this, add the following line of code to ~/.bashrc:
PROMPT_COMMAND='if [[ "$bashrc" != "$PWD" && "$PWD" != "$HOME" && -e .bashrc ]]; then bashrc="$PWD"; . .bashrc; fi'
Note: For a better understanding of what this line of code does refer to the "Explanation" section below.
The ~/.bash_profile file:
Typically your ~/.bash_profile contains the following line of code to load the ~/.bashrc file (or some variation of it):
if [ -f ~/.bashrc ]; then . ~/.bashrc; fi
If this is not present, then it must be added to ~/.bash_profile.
Additional info.
Setup/Configuration helpers:
Consider your developers utilizing the following two commands to aid configuration of their Bash startup files, as per the aforementioned steps two and three.
For step two, run the following command:
echo $'\n'"PROMPT_COMMAND='if [[ \"\$bashrc\" != \"\$PWD\" && \"\$PWD\" != \"\$HOME\" && -e .bashrc ]]; then bashrc=\"\$PWD\"; . .bashrc; fi'" >> ~/.bashrc
This will add the PROMPT_COMMAND=... line of code to the existing ~/.bashrc file, or create a new one if it doesn't already exist:
For step three, run the following command to append the line of code necessary in the ~/.bash_profile for loading the ~/.bashrc file:
echo $'\n'"if [ -f ~/.bashrc ]; then . ~/.bashrc; fi" >> ~/.bash_profile
Is my shell configured to Bash?
To check whether the shell is configured to Bash you can create a new session, i.e. create a new Terminal window and run:
echo $0
If it prints -bash then it's using Bash.
How do I configured my shell to Bash?
If echo $0 doesn't print -bash then you'll need to change the shell. To change it to Bash run:
chsh -s /bin/bash
Note: You'll need to create a new session for this change to become effective.
Explanation
The project specific .bashrc file:
This .bashrc file contains a shell function named npm. The body of this function contains the logic necessary to override the default npm install|i --save command.
The conditions specified in the if statement, i.e, the part that reads;
if [[ $* == "install "* || $* == "i "* ]] && array_includes --save "$#"; then
...
fi
essentially reads the $* special parameter to check whether the argument(s) passed to the npm function begin with either; install , or it's shorthand equivalent i , and whether the --save option/argument has been passed too.
To check for the existence of the --save argument we pass the $# special parameter to the array_includes function. We handle this argument differently because the position of the --save option may differ in the compound command. For instance, a user may install a package by running this;
# Example showing `--save` option at the end
npm install <pkg_name> --save
or this (or some other variation):
# Example showing `--save` option in the middle
npm i --save <pkg_name>
When the conditions specified in the if statement are met, i.e. they're true, we perform the following tasks in its body:
Run the given npm install --save ... command as-is via the line that reads:
command npm "$#"
Check whether the npx command exists globally via the part that reads:
command -v npx >/dev/null 2>&1 || {
log_warn_message npx
return 1
}
If the npx command is not available (globally) we warn the user that the npx snowpack command cannot be run, and return from the function early with an exit status of 1.
Note: My logic in this check assumes that you'll be installing npx globally. However if you're installing npm locally within your project then you'll need to change this logic. Perhaps by checking whether ./node_modules/.bin/npx exists instead. Or, you may be confident that npx command will always exists, therefore conclude that this check is unnecessary.
If the npx command exists globally we then run the pseudo "postinstall" command, i.e.
command npx snowpack
When the conditions specified in the if statement are NOT met, i.e. they're false, the user is essentially running any other npm command that is not npm install --save <pkg_name>. Therefore in the else branch we run the command as-is:
command npm "$#"
The ~/.bashrc file:
In section 5.2 Bash Variables of the "Bash Reference Manual" the PROMPT_COMMAND variable is described as follows:
PROMPT_COMMAND
If set, the value is interpreted as a command to execute before the printing of each primary prompt ($PS1).
So, this line of code (here it is again):
PROMPT_COMMAND='if [[ "$bashrc" != "$PWD" && "$PWD" != "$HOME" && -e .bashrc ]]; then bashrc="$PWD"; . .bashrc; fi'
loads the "project specific" .bashrc (if one exists), which in turn overrides the npm command with the npm function. This is what essentially provides a mechanism for overriding the npm install --save compound command for a specific project(s).
See this answer by #Cyrus for further explanation.
With newer versions of Snowpack (>=2) you can run snowpack dev and it will watch your npm_modules folder for new modules to build.
I think the best bet would be to create a new script that performs the desired action. Something along the following lines in your package.json:
{
"scripts": {
"snowpack-install" : "npm install --save && npx snowpack"
}
}
Correction
You can actually use the postinstall option in package.json. The postinstall will run "AFTER the package is installed". This would look something like the following:
{
"scripts": {
"postinstall" : "npx snowpack"
}
}
I have the below scripts in my package.json:
"scripts": {
"vumper": "node node_modules/vumper/index.js",
"format": "prettier --single-quote -width=80 --write package.json"
},
The 'vumper' package takes in a command line argument (such as 'dv'). What I would like to be able to do is have a command that runs both of these in succession.
Essentially, I would like to be able to run:
npm run vumber dv
and then
npm run format
but in one command, something like
npm run my-build dv
which would run both of the above commands, correctly accepting the command line argument 'dv' and passing it to the first npm run vumper. Is this possible?
Short Answer:
Essentially, what you're wanting is to have an npm-script something like this, whereby <arg-here> is provide via the CLI;
...
"scripts": {
"my-build": "npm run vumper <arg-here> && npm run format",
...
},
...
However, unfortunately npm does not have a built-in feature to achieve this.
The special npm option --, (refer to the end of Solution 1 below for further info about this option), can only be used to pass an argument to the END of a script but NOT into the MIDDLE. So, if your two commands were in the opposite order, the -- option could be used like this:
...
"scripts": {
"my-build": "npm run format && npm run vumper --",
...
},
...
To overcome the limitation of there being no built-in feature to pass an argument into the MIDDLE of a script consider the following solutions:
For a Bash only solution refer to the "Solution 1" section.
If cross platform support is required then follow the solution described in the "Solution 2" section.
Solution 1 - Bash (MacOS/Linux/ etc..):
Configure your my-build script in the scripts section of package.json to invoke a Bash shell function, as shown below:
package.json
...
"scripts": {
"my-build": "func() { npm run vumper \"$1\" && npm run format; }; func",
"vumper": "node node_modules/vumper/index.js",
"format": "prettier --single-quote -width=80 --write package.json"
},
...
Explanation:
The Bash function named func does the following:
Firstly runs npm run vumper <arg>. Whereby <arg> will be the shell argument passed via the CLI. It is referenced in the script using $1 (i.e. the first positional parameter/argument).
Subsequently it runs the script named format via the command npm run format.
These two npm run commands are chained using the && operator, so the second npm run format command will only run if the initial npm run vumper <arg> command completes successfully (i.e. returns a 0 exit code).
Running my-build script:
To invoke my-build via your CLI you'll need to run:
npm run my-build -- dv
Note:
In this instance the trailing dv part is the argument that will be passed to your vumper script.
The special option -- must be specified before the argument. The docs describe the -- option as:
... The special option -- is used by getopt to delimit the end of the options. npm will pass all the arguments after the -- directly to your script: ... The arguments will only be passed to the script specified after npm run and not to any pre or post script.
Solution 2 - Cross-platform:
For a cross-platform solution, (one which works successfully with Bash, Windows Command Prompt / cmd.exe, and PowerShell etc..), you'll need to utilize a nodejs helper script as follows.
run.js
Let's name the nodejs script run.js and save it in the projects root directory, at the same level as package.json.
const execSync = require('child_process').execSync;
const arg = process.argv[2] || 'dv'; // Default value `dv` if no args provided via CLI.
execSync('npm run vumper ' + arg, {stdio:[0, 1, 2]});
execSync('npm run format', {stdio:[0, 1, 2]});
package.json
Configure your my-build script to invoke run.js as follows:
...
"scripts": {
"my-build": "node run",
"vumper": "node node_modules/vumper/index.js",
"format": "prettier --single-quote -width=80 --write package.json"
},
...
Running my-build script:
As per Solution 1, to invoke my-build via your CLI you'll need to run:
npm run my-build -- dv
Explanation:
run.js utilizes process.argv to obtain the argument passed via the CLI (e.g. dv). If no argument is provided when running npm run my-build the default value, (i.e. dv), is passed to the vumper npm-script.
run.js also utilizes child_process.execSync(...) to shell-out/invoke the two npm run commands.
Npm now has a built-in option to pass cli arguments directly to scripts.
The cli arguments are stored in environmenet variables with prefix npm_config_<flagname>, and they required a very strict syntax, with the form --<flagname>=<flagvalue>.
Example:
"my-build": "npm run vumper %npm_config_myflag% && npm run format",
In the terminal, run npm run my-build --myflag=my_value to execute npm run vumper my_value && npm run format.
Note:
To refer the environment variable in the npm script, you have to use the platform specific syntax, ie %npm_config_myflag% in Windows or $npm_config_myflag in Linux.
UPDATE:
To avoid risks of conflict with the npm_config variables used to configure npm itself, just prefix your arguments with a unique prefix, such as the name of your app.
The potential conflict is a very common problem, which applies in many contexts: any application could use environment variables already used by other applications; for this reason, the environment variables are usually prefixed with the name of the application (eg NVM_HOME, JAVA_HOME). But this potential conflict is not a good reason to avoid using environment variables. The same in my opinion applies to npm params / npm_config env vars. The doc does not say anything about the risk of conflicts, implying I guess they should be managed as usual.
My preferred method is by using environment variables:
{
"scripts": {
"ncc-build": "ncc build $ACTION/src/index.ts -o $ACTION/dist",
"build:pr-changelog": "ACTION=pr-changelog npm run ncc-build",
}
}
It should work in UNIX systems. I'm not sure about windows platfrom compatibility though.
a different approach for doing this - to reach super deep into you dependency chain:
npm scripts section:
"test:local": "cross-env-shell UPDATE_BASELINE=false UPDATE_MODULE=%npm_config_vizdifsingle% run-p koa:ci wdio:local",
"test:remote": "cross-env-shell UPDATE_BASELINE=false UPDATE_MODULE=%npm_config_vizdifsingle% run-p localtunnel:start koa:ci wdio:remote"
by using crossenv and npm's value placement you can pass args to env.args
like this:
npm run test:local --vizdifsingle=some,value,or,values
it will be available to you in
process.env.npm_config_update_module
I'm trying to understand and follows https://github.com/DMPRoadmap/roadmap/wiki/Installation
But I don't understand something they use.
What does these do?
1) npm run bundle
I know it equals to npm run-script bundle as according to npm doc about run script but I don't really understand where the bundle come from; in other words, I don't understand what npm doc about run script mean by
an arbitrary command from a package's script object
2) npm run bundle -- -p
Since I don't know where the bundle come from, I don't know how to work out the meaning of -- -p option. I want to find its documentation and see the details.
I'm not sure if npm doc about bundle is related, but it seems to be replaced by install as documented in npm doc about install.
And why is this option got so many - characters (3 in this case) before p? I normally see 2 - for long option name and 1 - for abbreviated option name
Any time you see npm run [x] anywhere it means that it's executing a command located in the scripts section of the package.json file. Therefore npm run bundle runs the bundle command located here: https://github.com/DMPRoadmap/roadmap/blob/master/lib/assets/package.json#L8 which in this case looks like all it's doing is running webpack
"scripts": {
"test": "./node_modules/.bin/karma start",
"bundle": "./node_modules/.bin/webpack",
"lint": "./node_modules/.bin/eslint --ext .js --cache ./javascripts/ || true"
}
I have two separate projects that use npm - so I have both :
some_base_folder/projectA/package.json and some_base_folder/projectB/package.json
Each of those files has a scripts section in it.
If I go to some_base_folder/projectA/ and run npm run-script test it executes the test command from the scripts section of some_base_folder/projectA/package.json as it should.
What can I put as the value of "scripts": {test_projectA:'????' in some_base_folder/projectB/package.json so that when I am in some_base_folder/projectB/ and I run npm run-script test_projectA it will be
execute the test script of Project A?
I tried ../projectA/npm run-script test but it says:
'..' is not recognized as an internal or external command,
operable program or batch file.
I am running under windows 7 but would prefer a solution that would also work properly on linux.
well it turns out to be quite simple:
"scripts": {
test_projectA:"cd ../projectA && npm run-script test"
}
You should use --prefix.
npm run [command] --prefix path/to/your/other/folder
And for yarn:
yarn --cwd path/to/your/other/folder [command]
I ended up using:
"scripts": {
"job": "cd ./sub && \"$npm_execpath\" run subjob",
...
}
because this also works with yarn.