Using windows, I keep running into NPM errors when running scripts. Is pattern matching different between OSX and Win7? Or is this mocha specific?
For example, my tests are in:
src/redux/normalizers/__tests__
and the npm script is:
"test": "mocha --compilers js:babel/register --recursive 'src/**/__tests__/*'"
My console (also in screenshot below) says this:
> mocha --compilers js:babel/register --recursive 'src/**/__tests__/*'
C:\Users\User\WebstormProjects\redux-form\node_modules\mocha\lib\utils.js:626
throw new Error("cannot resolve path (or pattern) '" + path + "'");
^
Error: cannot resolve path (or pattern) ''src/**/__tests__/*''
screenshot: http://i.imgur.com/EL7LOna.png
Edit I was able to change the repo author's test script for the time being to
"test": "mocha --compilers js:babel/register --recursive src/**/__tests__/*"
Perhaps this is just an error on their part which nobody noticed because nobody else uses windows?
Still, I'd like to understand why. Maybe these links are useful for anyone who comes across this:
Cannot resolve path in Mocha
Two asterisks in file path
You don't need the single quotes. I was able to run the command you provided without them. Like so:
mocha --compilers js:babel/register --recursive src/**/__tests__/*.js
Related
I have a few different environments in which I am running Cypress tests (i.e. envA, envB, envC)
I run the tests like so:
npm run cypress:open -- --env apiEndpoint=https://app-envA.mySite.com
npm run cypress:open -- --env apiEndpoint=https://app-envB.mySite.com
npm run cypress:open -- --env apiEndpoint=https://app-envC.mySite.com
As you can see, the apiEndpoint varies based on the environment.
In one of my Cypress tests, I am testing a value that changes based on the environment being tested.
For example:
expect(resourceTiming.name).to.eq('https://cdn-envA.net/myPage.html')
As you can see the text envA appears in this assertion.
The issue I'm facing is that if I run this test in envB, it will fail like so:
Expected: expect(resourceTiming.name).to.eq('https://cdn-envB.net/myPage.html')
Actual: expect(resourceTiming.name).to.eq('https://cdn-envA.net/myPage.html')
My question is - how can I update the spec files so that the correct URL is asserted when I run in the different environments?
I am wondering if there's a way to pass a value from the command line to the spec file to tell the spec file which environment I'm in, but I'm not sure if that's possible.
You can directly use the Cypress.env('apiEndpoint') in your assertions, so that whatever you're passing via CLI, your spec files has the same value -
expect(resourceTiming.name).to.eq(Cypress.env('apiEndpoint'))
And if you want to check that when you pass https://app-envA.mySite.com and the url you expect in the spec file is https://cdn-envA.net/myPage.html, You can use:
expect(resourceTiming.name).to.eq(Cypress.env('apiEndpoint').replace('app', 'cdn').replace('mySite.com', 'net') + '/myPage.html')
Your best bet, in my opinion, is to utilize environment configs (envA.json, envB.json, etc)
Keep all of the property names in the configs identical, and then apply the values based on the environment:
// envA.json file
"env": {
"baseUrl": "yourUrlForEnvA.com"
}
// envB.json file
"env": {
"baseUrl": "yourUrlForEnvB.com"
}
That way, you can call Cypress.env('baseUrl') in your test, and no matter what, the right property should be loaded in.
You would call your environment from the command line with the following syntax:
"cypress run --config-file cypress\\config\\envA.json",
This sets up the test run to grab the right config from the start.
Calling the url for login, for example, would be something like:
cy.login(Cypress.env('baseUrl'))
Best of luck to you!
I use package.json variables like this in NPM scripts:
// package.json
{
"version": "0.12.1",
"scripts": {
"get-version": "echo %npm_package_version%"
}
}
npm run get-version currently echoes %npm_package_version% instead of 0.12.1. In the past, the scripts worked without any problems. Suddenly only the variable name comes back. With multiple repositories. I run Windows 10 2004 and NodeJS v15.4.0.
Was there a change for NPM scripts in Node.js 15? Is it a bug or a feature?
UPDATE: Failure to expand environment variables on Windows appears to be a recent high-priority known bug in the npm CLI.
Because this is npm#7 specific, until a fix is released, you can downgrade to npm#6.
ORIGINAL ANSWER:
The easiest solution for the specific case in this question is to use node.
"get-version": "node -p process.env.npm_package_version"
This will work on every platform that Node.js supports.
If you need a more general solution and don't want to rewrite a bunch of scripts to use node, you can try cross-var as mentioned by #RobC in the comments.
As for the source of the problem, perhaps you are running under the Windows bash shell, in which case you can use this:
"get-version": "echo $npm_package_version"
That won't work for non-bash Windows environments though.
I found simple hack which is working perfect in my case,
Specifically in your use case
// package.json
{
"version": "0.12.1",
"scripts": {
"get-version": "node -e \"console.log(process.env.npm_package_version)\""
}
}
Usage
npm run get-version
However you want to pass arguments.
// package.json
{
"scripts": {
"get-argument": "node -e \"console.log('your argument:', process.argv[1] )\"",
}
}
Test example
npm run get-argument hello_world
Default values are a great way to handle undefined values. We use a predefined value instead. Inside our NPM script we can achieve that by using the following syntax;
{
"version": "0.12.1",
"scripts": {
"get-version": "echo ${npm_package_version:0.99}"
}
}
And of course, running npm from a bash prompt might help. I guess running from a Cmd/Powershell "could work" but I would be careful about that.
FYI - A related change in Version 7 if you are using the Package config variables:
The variable name changed from npm_package_config_customFooVar in V6 to npm_config_customFooVar in V7
Delineate these appropriate (as below) to the environment (Windows bash linux etc) being used. or Use lib like cross-var.
Package.json
{
"config": {
"customFooVar": "bar",
"env": "development"
},
"scripts": {
"get-var": "echo using env1 $npm_config_customFooVar OR env2 %npm_config_customFooVar%"
"build": "npm config set myAppName:env"
"postbuild": "cross-var ng build --configuration=$npm_config_env && cross-var node myOtherBuildSript.js $npm_config_env"
}
}
e.g. npm-cli call (note space after --) as this is passed to the script. Not to npm itself.
npm run build -- production
pass args from package.json to cli
echo %npm_package_version%
This solution allowed me to use the npm_package_version variable in both Windows and Unix:
Install run-script-os as a dev dependency. Then in your package.json the variable can be used:
"scripts": {
...
"postversion": "yarn postversion-wrapper",
"postversion-wrapper": "run-script-os",
"postversion-wrapper:windows": "echo %npm_package_version%",
"postversion-wrapper:nix": "echo $npm_package_version"
}
I try to configure elm-coverage to be used in CI.
Installation was successful, installed using yarn as "elm-coverage": "0.2.0"
Our most recent command for running tests is
./node_modules/.bin/elm-test --compiler ./node_modules/.bin/elm app/frontend/elm/tests/
app/frontend/ is there, because elm app is within repository of rails app.
When I try to use coverage
elm-coverage --elm-test ./node_modules/.bin/elm-test -- --compiler ./node_modules/.bin/elm app/frontend/elm/tests/
in (ruby app's) root, it returns
MacBook-Pro-6:enectiva admin$ elm-coverage --elm-test ./node_modules/.bin/elm-test -- --compiler ./node_modules/.bin/elm app/frontend/elm/tests/
/Users/admin/git.enectiva.cz/enectiva/node_modules/elm-coverage/node_modules/find/index.js:33
throw err;
^
Error: does not exist.
at Object.notExist (/Users/admin/git.enectiva.cz/enectiva/node_modules/elm-coverage/node_modules/find/index.js:41:12)
at traverseAsync (/Users/admin/git.enectiva.cz/enectiva/node_modules/elm-coverage/node_modules/find/index.js:163:28)
at /Users/admin/git.enectiva.cz/enectiva/node_modules/elm-coverage/node_modules/find/index.js:282:7
at _combinedTickCallback (internal/process/next_tick.js:131:7)
at process._tickCallback (internal/process/next_tick.js:180:9)
Otherwise, I tried
MacBook-Pro-6:enectiva admin$ elm-coverage app/frontend/elm/tests/ --elm-test ./node_modules/.bin/elm-test
[12:57:01.68] Instrumenting sources...
[12:57:01.89] Something went wrong:
I searched through issues in Github repository, it does not seem to be reported bug, so there must be something I missed.
Does anyone know, how to actually use it?
OK, I've had a bit more of a play with elm-coverage, as I've been able to get it to run on an Elm project of mine.
Firstly elm-coverage has a --verbose flag which adds extra logging, so try running with that.
I've had best results if I cd to the folder containing my elm.json file and run elm-coverage from there. In your case, this would look something like the following:
cd app/frontend/elm && elm-coverage [source folder] --elm-test ../../../node_modules/.bin/elm-test
[source folder] is the name of the folder containing your source files (not the tests). For me, [source folder] is src, but because that's the default I can omit it.
I am having a problem testing UI components that import .scss with webpack. I am testing the component code directly, not the exported webpack bundle.
In my SUT
I have some code that imports scss:
import '!style!css!sass!postcss-loader!../style.scss'
This code causes an error when I run tests:
Error: Cannot find module '!style!css!sass!postcss-loader!../../stylesheets/parts/Breadcrumbs.scss'
at Function.Module._resolveFilename (module.js:336:15)
at Function.Module._load (module.js:286:25)
at Module.require (module.js:365:17)
at require (module.js:384:17)
Cheap workaround
I've been working around this issue with:
try {
require('!style!css!sass!postcss-loader!../style.scss');
} catch(err) { console.log('Not webpack'); }
But this smells dirty, and I would rather not have this code in my SUT.
Running Tests
I can't figure out how to work in the solutions that I have found for this when using babel-node and babel-istanbul instead of mocha directly. Here is how I am currently running tests:
$ babel-node babel-istanbul cover _mocha -- --require ./test/setup.js --recursive
All of the answers I have found are for mocha directly, but I am not running tests with:
$ mocha --compilers js:babel-core/register --require ./test/setup.js --recursive
?
How can I work in a compiler or setup file to tell mocha to ignore .scss files. I am going to have this problem next with .svg files too I am sure.
What about github.com/css-modules/css-modules-require-hook or if you wanna just ignore the css npmjs.com/package/ignore-styles
EDIT:
If you install ignore-style module and then run:
babel-node babel-istanbul cover _mocha -- --require ./test/setup.js --require node_modules/ignore-styles --recursive
im sure it will work, bare in mind you might need to change the path node_modules/ignore-styles im assuming you have your node_modules in the root of your project.
So I had a similar problem trying to require with a webpack-loader prefix and failing as not in the context of webpack.
prunk was better than rewire etc as covered me for all files as was able to do path matching and replacement.
var prunk = require('prunk');
prunk.alias(/^(your loader prefix)/, '');
Then I modified requires extension handling to replace what was being imported.
require.extensions['.scss'] = function (module, filename) {
module.exports = 'whatever you want';
};
(exactly what style-loader does but style-loader cleans itself up! Also note style loader is misnamed and can handle many extensions))
I added this at the top of my test runner and no unfound modules!
Note I actually went further and used the original loader by itself by reading in the file with fs and passing it to the loader but that may have been over kill and should be using webpack to transpile tests with that sole loader in the first place!
The info on this page seems less-than-forth-coming -- https://github.com/kof/node-qunit. I've got a setup where I installed nodejs and installed the node-quit module. I have test runner and executed the command node /path/to/runner.js. Below is an example of my setup. Any ideas or examples on how to do this or maybe I'm using it wrong. I previous ran qunit tests using Rhino and EnvJs without any issues but I figured I try nodejs since I using it for other things and the packaging system can be scripted in my build. Maybe I missing an option to node to include Qunit or some environment variable not set -- that would make sense.
File Structure
node/
public/
js/
main.js
tests/
js/
testrunner.js
tests.js
Installation
cd node
npm install qunit
This will now update the file structure.
node/
node_modules/
qunit/
tests/js/testrunner.js
var runner = require("../../node/node_modules/qunit");
runner.run({
code : "/full/path/to/public/js/main.js",
tests : "/full/path/to/tests/js/tests.js"
});
tests/js/tests.js
test("Hello World", function() {
ok(true);
});
Command
node tests/js/testrunner.js
It appears that you need to use full paths to the main.js and tests.js files and also include a relative path to the qunit module. I updated the code above as an example for others.