-
Notifications
You must be signed in to change notification settings - Fork 89
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
refactor: Argument parsing (>= node 16) #283
base: main
Are you sure you want to change the base?
Conversation
Why don't we add #282 first and then do a refactor here after. |
this should now be up to date with the changes in #282 |
Let's finish arg parse refactor here? We can merge later #283 (comment) . |
Should I edit on top of master or #284? |
#284 don't touch arg parse part, you can start from master branch, arg parsing should only effect L78-L110, isn't it? |
That does seem correct |
b0581a6
to
54270fd
Compare
This has been refactored on top of the main branch. The node 12 and 14 tests have both failed, as expected, because parseArgs is not supported in those versions. |
This moved argument destructuring to the parseCliArguments function, renames values to options, renames positionals to patterns, and moves the try catch to the run function
I have moved the try-catch to the run function, and moved destructuring to the parseCliArguments function. Also, there are now defaults(which I previously believed didn't work on node 16), so the boolean conversion is no longer needed. |
Nice! Good to know. |
Very nice! Can you add a test for |
Is that check in reporter.js on line 73(/63) necessary? We already define the logger functions based on options.shouldBeQuiet on line 18. |
It's not, this is why test still pass, but can avoid unnecessary calles. |
Also |
Should this be a global modifier, or only the last counts? ie, should |
Just make a snapshot, not really care how it works. |
Better use |
You do want --no-version to be a legal argument? |
Sorry for not been clear, I didn't expect you to handle |
Oh, so you just want a test that throws? Or do you prefer the new behavior? |
No, I just want snapshot to show how |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work!
error.code === 'ERR_PARSE_ARGS_UNKNOWN_OPTION' || | ||
error.code === 'ERR_PARSE_ARGS_INVALID_OPTION_VALUE' | ||
) { | ||
console.error(`Try 'sort-package-json --help' for more information.`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than telling the user to re-run the command with different arguments, can we just show the help?
console.error(`Try 'sort-package-json --help' for more information.`) | |
showHelpInformation() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer the current mode because it results in shorter output, making it more immediately clear what went wrong, rather than the user having to find the error message above the wall of text. If you are insistent that we should show the help menu, perhaps we move the error displaying to after the help, so the user can see what went wrong without scrolling
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about show it directly too, but I agree error message is more important to tell user what's wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@keithamus, thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy displaying an error message but I think it's important to show the help. Perhaps a more explicit error of --foo is not a valid argument
would also be better here?
To clarify - IMO we should show both help and an error telling them why they're seeing the help instead of the command running.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the util.parseArgs function doesn't seem to expose a way to determine the invalid argument which was passed, other than parsing error.message; however error.message has no guarantee of consistency between versions (Errors | Node.js).
Regarding displaying help, would you suggest the following, or the error at the end? I feel that the help might be slightly overwhelming when just searching for the error.
$ sort-package-json --not-an-option
Unknown option '--not-an-option'. To specify a positional argument starting with a '-',
place it at the end of the command after '--', as in '-- "--not-an-option"
Usage: sort-package-json [options] [file/glob ...]
Sort package.json files.
If file/glob is omitted, './package.json' file will be processed.
-c, --check Check if files are sorted
-q, --quiet Don't output success messages
-h, --help Display this help
-v, --version Display the package version
I personally prefer the shorter output (see below), as it directly tells the user what went wrong, without having to find it, as well as telling them how to find help if they aren't sure already how to fix their error.
$ sort-package-json --not-an-option
Unknown option '--not-an-option'. To specify a positional argument starting with a '-',
place it at the end of the command after '--', as in '-- "--not-an-option"
Try 'sort-package-json --help' for more information.
Additionally, this is the format followed by many default tools, such as ls
, df
, du
, and diff
:
$ df --not-an-option
df: unrecognized option '--not-an-option'
Try 'df --help' for more information.
$ ls --not-an-option
ls: unrecognized option '--not-an-option'
Try 'ls --help' for more information.
$ du --not-an-option
du: unrecognized option '--not-an-option'
Try 'du --help' for more information.
$ diff --not-an-option
diff: unrecognized option '--not-an-option'
diff: Try 'diff --help' for more information.
The other reasonable possibility is to display an abbreviated usage menu, such as the one displayed by git
(below), however this forces the maintenance of both help menus when the arguments or usage of the cli changes.
$ git --not-an-option
unknown option: --not-an-option
usage: git [--version] [--help] [-C <path>] [-c <name>=<value>]
[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p | --paginate | -P | --no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
[--super-prefix=<path>] [--config-env=<name>=<envvar>]
<command> [<args>]
are we ready to start looking at merging this PR again, because the node 12 EOL was reached, or are we still supporting V12? |
This PR uses node:util.parseArgs for parsing arguments, allowing easy future extendability. The output of the tool remains the same as previous commits but user usage may change. Previous use cases which did not rely on the use of arguments beginning in '-' should remain unchanged, but in this update, arguments which begin with a dash must follow the argument '--', which follows general user expectation. Each of the options(check, quiet, version, and help) have a corresponding short option(c,q,V,h) which can be combined into one (ie -cq = -c -q).