I am using WebdriverIO.
I start my tests from the command line using 'npm test', which triggers the command: wdio wdio.conf.js as specified in my package.json here:
"scripts": {
"test": "wdio wdio.conf.js"
},
What I want to do is specify the actual test to run like this:
wdio wdio.conf.js --spec ./test/specs/e2e/login.js
My question is, how do I pass in the testcase from the npm command, i.e. how can I pass this --spec ./test/specs/e2e/login.js from the npm command into the wdio command?
You can do something like this.
npm run test -- --spec ./test/specs/e2e/login.js
Check this out. https://stackoverflow.com/a/14404223/3879644
Related
In cypress.json there is one env variable:
"env": {
"AUTH_TOKEN": "token_1"
},
I have multiple users in db and would like to test them separately without editing cypress.json. Cypress documentation provides two possible ways how to override env variables form command line:
cypress run --env AUTH_TOKEN="token_2"
and
AUTH_TOKEN="token_2" cypress run
When I run cypress interface with
npm run cy:open --env AUTH_TOKEN="token_2"
or
AUTH_TOKEN="token_2" npm run cy:open
token_1 does not get overriden with token_2. Why is cypress ignoring options provided in command line?
npm run requires a -- to pass parameters to script cy:open in package.json,
npm run cy:open -- --env AUTH_TOKEN="token_2"
or use yarn
yarn cy:open --env AUTH_TOKEN="token_2"
or bypass the script
yarn cypress open --env AUTH_TOKEN="token_2"
or
npx cypress open --env AUTH_TOKEN="token_2"
I have installed cypress using npm as npm install cypress --save-dev .
I used the same command in .gitlab-ci.yml file
When i run the command npm run cypress run locally , IDE opens and when i double click the spec.js file , then the tests run.
But I i use the same command on the gitlab pipeline , it says
cypress open "run"
It looks like this is your first time using Cypress: 4.1.0
[07:45:16] Verifying Cypress can run /osmc/ux/framework-acceptance-tests/cache/Cypress/4.1.0/Cypress [started]
[07:45:18] Verifying Cypress can run /osmc/ux/framework-acceptance-tests/cache/Cypress/4.1.0/Cypress [completed]
Opening Cypress...
and build fails .
Am i missing anything here ?
It's because it's opening the test runner, which is used locally via npx cypress open.
From that output it looks like you're running npx cypress open run, which isn't a real command and will open the runner
In CI you need to use npx cypress run, which will run tests without user interaction. https://docs.cypress.io/guides/guides/command-line.html#How-to-run-commands
Your gitlab.yml file should accomodate for the npm installations.
One example is as below. Meanwhile also please check the test/run command for your specs under package.json file. use the same command to trigger the test in pipeline.
stages:
- test
test:
image: cypress/browsers:node12.14.1-chrome85
stage: test
script:
npm i
npm run start:ci &
npx cypress run
You should have your .gitlab-ci.yml with:
stages:
- test
cypress-test:
image: cypress/browsers:node16.14.0-slim-chrome99-ff97
stage: test
script:
- npm ci
- npx cypress run
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 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 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.