Skip to content
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

remove yargs-unparser; run yargs only once #3833

Conversation

cspotcode
Copy link
Contributor

@cspotcode cspotcode commented Mar 14, 2019

Requirements

  • Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
  • All new code requires tests to ensure against regressions.

Description of the Change

This removes the yargs-unparser dependency and avoids loading yargs within _mocha unless necessary. I still need to double-check these results, but it seems to reduce the installed size from 12M to about 6.6M.

Alternate Designs

Why should this be in core?

Faster startup and install time; simpler runtime behavior because yargs is only running once.

Benefits

Faster startup and install time; simpler runtime behavior because yargs is only running once.

Possible Drawbacks

Applicable issues

@cspotcode cspotcode changed the title Feature/json instead of yargs unparser remove yargs-unparser; run yargs only once Mar 14, 2019
@boneskull
Copy link
Member

@cspotcode did you disable the pre-commit hooks? eslint should have fixed the lint failures automatically (assuming it could)

@cspotcode
Copy link
Contributor Author

cspotcode commented Mar 14, 2019

I didn't run eslint (EDIT or prettier or anything else), no. I still need to cleanup this PR before it's ready to merge; I'll fix the linter failures and squash all those commits.

@coveralls
Copy link

coveralls commented Mar 14, 2019

Coverage Status

Coverage increased (+0.1%) to 91.818% when pulling 654fee2 on cspotcode:feature/json-instead-of-yargs-unparser into 0098147 on mochajs:master.

Pass parsed args object to spawned process as JSON string.
@cspotcode cspotcode force-pushed the feature/json-instead-of-yargs-unparser branch from 7e072e1 to 654fee2 Compare March 14, 2019 03:57
@cspotcode
Copy link
Contributor Author

This is ready for review. I didn't need the base64 encoding on Windows, so I moved that to another branch just in case it's relevant in the future.

Installed size drops by about half, with more modest improvements in startup time.

@boneskull boneskull self-requested a review March 14, 2019 19:37
@@ -123,7 +121,8 @@ debug('final node args', nodeArgs);
const args = [].concat(
unparseNodeFlags(nodeArgs),
mochaPath,
unparse(mochaArgs, {alias: aliases})
'--preParsedJsonOptions',
JSON.stringify(mochaArgs)
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This way duplicate alias options don't get eliminated. With unparse() we get a clean array without any aliases, so I'm not sure wether we can do without unparse() as easily.

It's a very good idea not to parse a second time in "/cli.cli.js".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's necessary to remove duplicate alias options using this method. They won't pass through yargs' parser again; the object is passed straight to mocha.

When mocha v6 re-parses the output of yargs-unparser, it creates those duplicate aliases all over again. So either way, the output object contains aliases, and mocha is built to handle it.

Copy link
Member

@juergba juergba Apr 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think the mocha instance looks quite messy with all those aliases, but it seems to be able to handle them correctly.

[...]; the object is passed straight to mocha.

This could be too early, since the coerce function of reporter-option hasn't run yet?

return exports
.createYargs()
.parse(argv, Object.assign(loadOptions(argv), {command: {}}));
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't understood yet (neither in the current master) why the object returned by loadOptions() is passed as context parameter to parse().

Copy link
Contributor Author

@cspotcode cspotcode Apr 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, sounds like a separate bug. EDIT: I'm also not sure why mocha would even allow aliases in a config file; seems like it introduces confusion without much benefit.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even node flags are allowed in config files. When run with _mocha they are useless, I don't think they get filtered out, probably they are just ignored.

@juergba
Copy link
Member

juergba commented Apr 17, 2019

I tried to fix that separate bug mentioned above: juergba/issue/3826.

You will not like it, because I'm using "yargs-unparser". Maybe you can merge my fix into this PR, otherwise I would open a seperate PR.

@cspotcode
Copy link
Contributor Author

cspotcode commented Apr 17, 2019 via email

@juergba
Copy link
Member

juergba commented Apr 18, 2019

We use "yargs-parser" to read CLI-argv plus all config files. Mocha has its own wrapper function parse() for this purpose. The resulting totalised argv is then passed to "yargs" to run the final coercing.

Yargs#parse([args], [context], [parseCallback])
IMO the seperate bug results, because the config object is passed as "context" parameter. This is wrong, or at least I haven't understood the reason.

@soryy708
Copy link

soryy708 commented Jul 13, 2019

Looks like yargs-unparser (1.5.0) depends on lodash (4.17.11) and GitHub claims there's a prototype pollution vulnerability in versions < 4.17.13.
Removing the yargs-unparser dependency not only optimizes, but also fixes a security vulnerability.

Edit: Here's relevant issue: #3965

@soryy708
Copy link

@cspotcode You've got merge conflicts.

@cspotcode
Copy link
Contributor Author

@soryy708 If the maintainers say they want to merge this change, I'll resolve the merge conflicts. Until then, it's not worth the potentially wasted effort.

@stale
Copy link

stale bot commented Nov 10, 2019

I am a bot that watches issues for inactivity.
This issue hasn't had any recent activity, and I'm labeling it stale. In 14 days, if there are no further comments or activity, I will close this issue.
Thanks for contributing to Mocha!

@stale stale bot added the stale this has been inactive for a while... label Nov 10, 2019
@stale stale bot closed this Nov 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale this has been inactive for a while...
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants