Windows support #13
Comments
|
Something screwy with the colon character in the path name that is confusing istanbul. Damn, I wish I had an easy way to reproduce windows issues. Do you have a VM or something I can use to play with this. Windows is the biggest gap in tests for istanbul |
|
I have a personal Windows 7 VM that I have setup with Node and git, but nothing that I can share as its in my server closet in IL ;) |
|
Could you run |
|
The output of |
|
Ok, here's some info for you. If I change my test script to:
From:
It works. On Windows, the |
|
Thanks for the info. This is going to be really tricky, if not impossible.... Bascially, the "command processing" is done using |
|
Also, off-topic - does the HTML reporting work correctly on Windows? I don't have a single test for this and it's the reporting that has path-delimiter specific code. |
|
Yeah, I figured as much. If I have some time, I may see what I can come up with to help out since I have a fully functional windows dev environment here. |
|
The reporting works and looks ok. It renders all the |
|
Let me work on getting a Windows machine up and running - I think I'll pinch my son's machine for this. Totally agree that everything should work the same on windows. |
|
Everything seems to be working ok on Windows, but I have one small question: Say I have the following folder structure: lib/
tests/
index.js (main file that requires all the tests) If I run The main html coverage stats file is in coverage, but shouldn't the rest also be there... ? (I haven't had time to test the library in OSX / Ubuntu yet to see if it's the same there). I really hate having all those .html files laying around everywhere. Thanks |
|
Ok followup: so normally istanbul should put the html files inside /coverage/lcov-report/ (and specific files inside the folder ProjectName). The thing is in Windows it only puts /coverage/lcov-report/index.html there, the rest of the html files are dispersed all over the place (wherever there's a covered_test_file.js it will put the html in the same folder). More details about my setup: Windows 7 and: $ node -v && npm -v
v0.6.11
1.1.1Anyway, I'm happy it works in OSX/Linux :D |
|
Can you install the latest node on Windows and check it against that first? |
|
Anyone else still having problems in Windows? I still get that same kind of error like this: |
|
ok, so the "magic" expansion of commands to JS files only works on Mac/ Unix because the executable files directly resolve to the JS files that have shebangs in them. On windows, you need to actually pass the JS file name that the mocha command uses, since in that environment the commands resolve to batch files and not JS files. |
|
Hmm.. well, I'm installing a linux vm irght now :-P But, I tried this too: istanbul cover test.js And it told me it could not find 'describe'. So, I assume I somehow have to include mocha in the command. |
|
right - |
|
@JogoShugh @gotwarlost I ran into the issue with |
|
When trying to run istanbul using I've updated mocha to the latest version and everything works fine and all tests pass. Any idea what could be causing this? |
|
See my previous comment, reproduced for your benefit: so the "magic" expansion of commands to JS files only works on Mac/ Unix because the executable files directly resolve to the JS files that have shebangs in them. On windows, you need to actually pass the JS file name that the mocha command uses, since in that environment the commands resolve to batch files and not JS files. |
|
@gotwarlost Thanks for the response. I just skimmed through the thread - silly me. Sorry for the inconvenience! |
|
I didn't understand at all what @gotwarlost was saying, since file expansion could apply to istanbul or mocha, but then I saw @mscdex link an issue that contains a PR with the actual fix. Posting here if anyone else was confused: |
|
@gotwarlost Could the "magic" expansion be fixed if you added a command line flag to trigger a lookup through the module loader? Add a flag that is used like this: Which transforms the parameter in a manner similar to this: var path = require('path');
function lookupBinPath(inputCommandName) {
var parts = inputCommandName.split('/');
var packageName = parts[0], commandName = parts[1];
// If no slash is present, look for a command with the same name as the package
if (commandName == undefined) commandName = packageName;
// Look up the package.json
var packageJSON = require(packageName+'/package.json');
//Extract the binary path
var relativeBinaryPath = packageJSON.bin[commandName];
// prepend the module name and pass it to require.resolve
return require.resolve(path.join(packageName, relativeBinaryPath));
} |
|
I am using this command |
|
That seems to be an error in parsing your Javascript. Are you sure it is well-formed? |
|
I tested and can confirm that it persists in istanbul |
|
I am using the latest version of Istanbul and I have a similiar problem in Windows 8. This does not work:
But if I add the path to the jasmine executable it works:
|
|
This is still an issue for me on Windows 10 using git-bash from git for Windows 2.8.3-64 from [1]. but if I pass the full path to _mocha it works, Here are some details of what is installed on my system: Could it be due to previously Let me know if gathering any additional command output or file contents would be helpful. |
|
Still an issue with but works |
|
node -v
npm -v
use istanbul as devDependencies. used script:
it works! |
|
same as @scott-plutovr I alse see this error under git-bash |
see gotwarlost/istanbul#13 for more details
|
Still relevant. |
|
I also have this issue with node 10.1.0 on a windows machine. |
|
I guess we should setup appveyor and try to find solutions. |
see gotwarlost/istanbul#13 for more details
|
It seems like this is working for node versions 6 and 8, but it doesn't work for node version 10. I had to uninstall 10.15.3 and revert back to 8.15.1. |
You can use nvm and alternatives to switch versions. |
NVM doesn't work for me on an x64 Windows 10 system. I'm noticing there's no stdout when I'm running my coverage combined with _mocha.
produces the coverage results without outputting the describe and it blocks during testing. |
I did not say that nvm can be used on Windows (in general). |
|
you could use something like: npx node@8 node_modules/istanbul/lib/cli.js cover *.test.js node_modules/mocha/bin/_mocha |
|
On WSL and Git Bash much more solutions should work. |
|
WSL is not Windows either. |
We can test with Travis CI. |
|
@DanielRuf I don't think this repo is maintained. According to the readme:
|
|
But I think it is better to use another code coverage solution (v8 internally provides this already). The last (tagged) release was in 2016 and last commit in 2017:
Right, time to migrate then I guess. Was not clear enough in the readme. |
|
https://github.com/istanbuljs/nyc it is then. |
|
If you're having this issue and you're on a Windows machine, all you need to do is to specify the full path of mocha to istanbul like so; |
My
istanbul covercommands fail on windows, but thevows --spec ./test/foo.jsworks fine.I get this error:
For reference, that vows is running:
The text was updated successfully, but these errors were encountered: