8000
We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
There was an error while loading. Please reload this page.
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
0f6b91d
2abc1a8
9b4c6f0
79b5f09
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
just noted, there is a Mocha flag -r and also one in nodeEnv . In this case flag is put into mocha bucket. Could lead to conflicts?
-r
nodeEnv
Sorry, something went wrong.
Mocha's --require and -r are both preferred over Node's, see isNodeFlag in lib/cli/node-flags.js
--require
isNodeFlag
lib/cli/node-flags.js
down L131: when Node env variable NODE_OPTIONS is used, it just feeds the CL arguments list, I guess. Does the child process inherit these variables correctly?
the short answer is "yes". the longer answer is we ignore NODE_OPTIONS, and whatever's there does not go into any arguments list. when node args and NODE_OPTIONS conflict, node does whatever node does to resolve it.
NODE_OPTIONS
(sic)
we save ALL found node args here so we can use them in the boolean array below. the values are saved as whatever they are; if there is no value (e.g., --inspect), then the value is saved as true, which is what yargs-unparser understands.
--inspect
true
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
This one is failing with "Uncaught UnexpectedError" on my Windows. I need to investigate further. The other three "Node.js v8+" tests do pass. "Node.js v6" tests are skipped.
yes, I don't know how to fix this. that's where I was hoping you could help (eventually)
killing the subprocess using our method (because inspect-brk means you're in a debugging session) doesn't return any process output nor an exit code on windows. the method is likely wrong for windows (using SIGINT on posix), but I don't know what the correct one is.
inspect-brk
SIGINT
change to:
setTimeout(function() { process.kill(proc.pid, 'SIGINT'); }, 2000);
This way the err.code is 1 (not undefined which crashes to have failed). A timeout of 1000 is too short, res may not be ready, yet => to contain output fails.
err.code
to have failed
res
to contain output
On my windows platform the four 'Node.js v8+' tests do pass.
I don't quite understand what you're asking for