cli: fix the misalinged text on "node --help"

[aashil]

The alignment of the argument descriptions in the "node --help"
text is off. This commit fixes the issue by adding two spaces
before each of the argument description.

Fixes: #10935

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

Affected core subsystem(s)

cli

[evanlucas]

Thanks @aashil! Can you prefix the commit message with src: instead of cli: please?

[cjihrig]

Does the --help menu currently enforce an 80 character limit? If so, does this cause any of the lines to go over that limit? If not, LGTM

[joshgav]

LGTM - thanks!

[jasnell]

Agree with @cjihrig's concern. If this causes any lines to go over 80, then that should be fixed. Otherwise LGTM

[aashil]

@evanlucas Sure, will do it.
@cjihrig Yes, it enforces the 80 line limit. I moved few words to confirm with the linter. All good. On a side not, why don't we have a test integration on Github which tests this automatically?

[cjihrig]

On a side not, why don't we have a test integration on Github which tests this automatically?

Because you didn't write it yet! :-D

[aashil]

@cjihrig Can I help with setting it up? If yes, I would like to submit an issue and start working on it.

[cjihrig]

I would just add a test to this PR. You can spawn node --help as a child process and validate the output.

[aashil]

I think we already have cpplint setup which tests for the 80 character limit here. From what I understand, the CI should automatically boot up the cpplint on submitting a PR. Please correct me if I am wrong.

[cjihrig]

Linting would run on the source code. I was referring to the actual message printed to the console.

[aashil]

Ah, makes sense. Can you please point me to the file where I need to write the test ? Thank you.

[cjihrig]

I would create a new test in test/message. Create a .js file that just runs node --help. The test output will be verified using a .out file, like the others in that directory.

[aashil]

Thanks. Will add the test soon.

[aashil]

@cjihrig I wrote a test as discussed but the test is reading the message from the node_help.out file with escape parameters while the child spawned process prints plain text(without escape parameters) to the process.stdout. Hence the comparison fails. Please look at the [WIP] commit I just pushed and the error log below for more clarity. Any suggestions about the escape parameters?

Error:

[00:01|%  33|+   8|-   0]: release node_help match failed  
line=0
expect=^Usage\:\ node\ \[options\]\ \[\ \-e\ script\ \|\ script\.js\ \]\ \[arguments\]$
actual=Usage: node [options] [ -e script | script.js ] [arguments] 

[Trott]

@aashil [arguments] has a space after it in the actual output that is not reflected in the node_help.out file. That is likely the source of the test failure. (The escaping you see is regular expression escaping and is likely not the problem.)

[aashil]

@Trott Added the space after it. Still the same error. This time I did node --help > test/message/node_help.out

[Trott]

This and use-openssl-ca need to be aligned.

[aashil]

Fixed.

[Trott]

CI: https://ci.nodejs.org/job/node-test-pull-request/6062/

[aashil]

It appears that test/linux-fips expects the below two options in the .out file. Is there a workaround for this like the wildcard character? Not sure about test/arm test.

--enable-fips              enable FIPS crypto at startup
--force-fips               force FIPS crypto (cannot be disabled)

[Trott]

The ARM thing is just a problem with the GitHub widget. It's just the FIPS issue that we need to figure out.

As best as I can tell from looking at test/messages/testcfg.py with my limited Python knowledge, there's no way to have alternative outputs with different line counts. (Correction from someone more knowledgable would be welcome.)

So given that, it seems like the options are:

• Move this out of messages and do the testing in parallel instead, which means reducing the amount of checking we're doing or else rewriting a lot of the messages test harness functionality in parallel.
• Try to use messages.status to skip the test on FIPS (may require adding a feature to the test harness)
• We can't use common.skip() in messages tests the way we can in other tests, so this isn't really an option but mentioning it here to pre-empt questions about it.
• Find a way to strip out those two FIPS options lines in the test itself.

Looking at node.cc, though, there's all sorts of other options that are only printed conditionally such as crypto and Intl. Given that, I wonder if the first option (move to parallel) might be the way to go. Maybe instead of checking the whole usage message, you just check for a few basic things, like any late that starts with - also has whitespace followed by non-whitespace in whatever the column is where the text is aligned.

I'm not sure I'm communicating the idea clearly above, but that may be OK for now because I'm starting to wonder if trying to have the test be in this PR may be creating more problems than it's solving. Maybe we should strip it out of this and open a separate PR for it. Then the alignment fix for the usage text can land sooner and the test can take as much time as it takes. Normally, I'm not in favor of landing tests after functionality, but this isn't really functionality. It's formatting. I'm OK with the test coming later. We've gone this long without a test for it...

In case I'm missing an obvious solution that can easily be implemented, thus invalidating nearly everything I've written above: /cc @nodejs/testing

[Trott]

@aashil Is it OK with you if I land the alignment fix and we push the test issue to another PR?

[aashil]

Sure, Rich. I would like to work on the test issue PR as well. Will create a new PR in the weekend.

[Trott]

Updated to just include changes to alignment in help message.

CI: https://ci.nodejs.org/job/node-test-pull-request/6085/

[Trott]

Landed in 5d27cc1.
Thanks for the contribution! 🎉

[evanlucas]

This isn't landing cleanly on v7.x. Mind opening a backport pr targetting v7.x-staging?

[Trott]

@evanlucas Might be best to backport 6ff3b03 first.

[aashil]

I can backport both if you want.

[evanlucas]

@aashil that would be awesome! Let us know if you have any questions on how to backport! Thanks!

[aashil]

From what I understand about backporting, first I need to create a branch off upstream/v7.x-staging and install the node version (7.x) in that branch. Thereafter, I need to make a copy of those commits (cherry-pick) and make sure it runs of v7.x. Just want to make sure I am on the right path.