New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NYC output is empty with mocha installed globally #1029
Comments
This repo seems to work on Linux. Is this a Windows specific issue? I was able to get coverage by running with globally installed nyc and mocha. |
Probably it's Windows specific. I suspect the reason of this issue is something very dumb, like file paths or similar. |
output is also empty on mac (node 10.15.3 and nyc ^9.0.1 and yarn 1.13.0, oof yarn/nyc should be updated), it's probably not windows-specific. so, just for the sake of completeness, here's me just brute-forcing my way to a working combination of node, nyc and yarn on mac. i'm using
and so far no luck:
|
FWIW: I experienced troubles launching mocha tests from VSCode with the above config so I created a workaround, see https://github.com/Antonius-S/Node_Articles/tree/master/Global_nyc_and_mocha |
another workaround i put together yesterday, which might make people cringe, is to use npm to call the test runners. it seems the issue is yarn isn't bubbling up information from the test runs to nyc. but npm can do it. |
@Antonius-S are you using yarn? If so please see if this issue can be reproduced with npm. |
@coreyfarrell no I use npm |
fixed by #822 (comment) |
that's not quite a fix, is it? it's more of a workaround to exit mocha cleanly? |
Doesn't help in my case. |
Experiencing this issue as well. Although I have not seen a difference when running locally or globally. I've tried the discussed solutions in other issue threads and have had no luck. MacOS Mojave@10.14.1, |
@captnseagraves could you create a different PR, with a repo that reproduces your issue? I think that you're probably bumping into something slightly different, this issue specifically relates to a globally installed version of mocha. |
we make an effort not to include files when they're outside the directory that is under test, I have a suspicion that this might be the root cause of this bug ... feature? If anyone is interested in taking a look, I would look for our logic that excludes files outside the test directory, and remove it temporarily -- if this does turn out to be the issue, maybe we could add a config option for this. |
But files under test are in the same folders in both cases. And global mocha shouldn't generate any files outside package under test. |
Hey, I had the same issue. In my case, following steps helped me:
instead of
I hope that my solution would helpful for you |
Can confirm @marek629 solution works for me. In my case, I just need to change from "test": "mocha -r ts-node/register test/**/*.test.{ts,tsx}",
"cover": "nyc yarn test", to "cover": "nyc mocha -r ts-node/register test/**/*.test.{ts,tsx}", |
After maaaany hours of debugging I finally found the problem. It's the They check if the node executable is in the same directory as they are, when they are installed as modules they work because there's no node executable there and it then relies on using the one in the PATH, but it's there when installed globally. That's not a problem on Unix because it uses a symbolic link to the JS file. Unless you use a Windows installation on Unix, then you have the same bug. My solution right now is to patch diff --git a/index.js b/index.js
index 908be7f..306b5ce 100644
--- a/index.js
+++ b/index.js
@@ -147,6 +147,21 @@ function setup(argv, env) {
fs.writeFileSync(path.join(workingDir, cmdname), shim)
fs.chmodSync(path.join(workingDir, cmdname), '0755')
}
+ if (cmdname === 'node') {
+ var nodePath = path.dirname(process.execPath)
+ var cmds = JSON.parse(env.NYC_CONFIG)._
+ cmds.forEach((cmd) => {
+ var filepath = path.resolve(nodePath, cmd)
+ if (fs.existsSync(filepath + '.cmd')) {
+ var windows = fs.readFileSync(filepath + '.cmd', 'utf8')
+ var unix = fs.readFileSync(filepath, 'utf8')
+ fs.writeFileSync(workingDir + '/' + cmd + '.cmd', windows.replace('"%_prog%" "%dp0%', '"%_prog%" "' + nodePath))
+ fs.chmodSync(workingDir + '/' + cmd + '.cmd', '0755')
+ fs.writeFileSync(workingDir + '/' + cmd, unix.replace('"$basedir/node" "$basedir', '"$basedir/node" "' + nodePath))
+ fs.chmodSync(workingDir + '/' + cmd, '0755')
+ }
+ })
+ }
fs.writeFileSync(path.join(workingDir, 'settings.json'), settings)
return workingDir It's a very dirty solution honestly but haven't put much effort. |
@An-dz thanks for the digging, mind opening even a rough PR with your patch, that way this is less likely to be dropped on the floor. |
Done. It's pull request #104 on spawn-wrap. |
Please retest using nyc 15 which replaces spawn-wrap with another method of wrapping child processes. |
Just used nyc 15 with AVA and it's working. |
If others are still experiencing this issue with nyc 15 please comment with a link to a reproduction and we can reopen. |
+1 with same Issue, upgraded from nyc 12.x.x to 15.1.0 and added the .nycrc file and empty coverage
|
I got coverage after separating app.listen() to another file. |
Issule simal to istanbuljs/nyc#1308 (i'm using nvm) Thanks to istanbuljs/nyc#1029 (comment), mainly
* add service field to tcpmanager logs * add correct type to logger * corect service name for logger * formatting * corect coverage settings Issule simal to istanbuljs/nyc#1308 (i'm using nvm) Thanks to istanbuljs/nyc#1029 (comment), mainly * remove circular require * remove final typescript mentions move typescript to a dev dependency * exclude the app launchers * test if deepcode accept this form of jsdoc * improve jsdocs * better type management * remove taprc
Extracted from #822
I experience no coverage output when both nyc and mocha installed globally (in fact, only mocha installation plays role).
Reproducible repo is here
Env:
Windows 7
Node 10.15.1
Nyc 13.3.0
Mocha 6.0.2
The text was updated successfully, but these errors were encountered: