feat: add MOCHA_OPTIONS env variable #4835
Conversation
|
@juergba have you had a chance to look this over? |
|
This PR hasn't had any recent activity, and I'm labeling it |
|
This PR hasn't had any recent activity, and I'm labeling it |
|
@outsideris I still need this feature. Would I be able to get some feedback? |
|
Yes! |
|
Yay! We're not quite ready to start reviewing PRs yet, but hope to soon. Note that I don't see any linked issues. The contributing guidelines right now ask for that so that folks can discuss the change first. We'll continue to require that after #5038. Was there any impetus for this PR besides what's in the description? |
|
There's no separate issue, the PR description contains all the context I have. I can create an issue if you'd like though. |
|
That would be lovely, yes please! Note that the three of us new maintainers are still ramping up on the project, so it might be some weeks (or even months 😞) before we have enough context to really triage the issue and review this PR. We'll do our best to get to it soon though! |
|
That's alright. It's been two years, what's another month or two? |
JoshuaKGoldberg
added
status: waiting for author
icholy
force-pushed
the
master
branch
2 times, most recently
from
ce9ba6b to
d79e034
Compare
JoshuaKGoldberg
removed
the
status: waiting for author
|
Sad to say nothing 😞 we're just waiting on the other maintainers. I know they've been pretty busy this season but I've sent pings privately. |
There was a problem hiding this comment.
I don't see how it could live anywhere else.
One can set up a .mocharc.js file that reads from process.env as exemplified here: https://github.com/mochajs/mocha/blob/master/example/config/.mocharc.js#L3-L5
But after thinking about this I see little harm in adding this option.
The one thing that we maybe would want to add down the line is a flag that opts out from MOCHA_OPTIONS to be read and used, but lets deal with that when the need is proven.
Approved 👍
(Sorry for slow review, have been crunching on neostandard + been pondering whether an environment option like this could become an injection attack of some kind, but after some googling I can't find much written that would discourage it)
If someone has write access to your env vars its already game over. |
Yeah, but sometimes people try to issue vulnerability reports for the strangest of things |
|
This was released in |
Description of the Change
The
MOCHA_OPTIONSenvironment variable is a space-separated list of command-line options. It essentially copies node's approach with NODE_OPTIONSThe config priority is:
MOCHA_OPTIONSenvironment variable..mocharc.c?js,.mocharc.ya?ml,mocharc.json)mochaprop ofpackage.jsonlib/mocharc.json)Alternate Designs
Yargs has support for env variables: https://yargs.js.org/docs/#api-reference-envprefix
However, using this feature would result in a separate env variable for each option:
Ex:
MOCHA_BAILMOCHA_ALLOW_UNCAUGHTMOCHA_FAIL_ZEROI decided to to go with
MOCHA_OPTIONSbecause it seems less intrusive and that's how node does it too.Why should this be in core?
I don't see how it could live anywhere else.
Benefits
My specific use-case is specifying
MOCHA_OPTIONS='--inspect-brk'when callingnpm run testfrom vim.Possible Drawbacks
Applicable issues
Fixes #4330.