Make positionals opt-in when strict:true #116
Conversation
|
From #85 (comment)
I think giving authors insight into the design helps smooth the experience, so more likely the API works the way they expect it to work because we guided their expectations (#85 (comment)). I am interested in seeing a sentence or two in the docs to spin the config-what-you-accept story or similar. I was thinking outside the documentation of the properties themselves and tying in the options. |
Makes sense. I've added the following sentence as a start, though I'm happy to try to expand this section:
|
| @@ -141,11 +142,13 @@ function storeOption(longOption, optionValue, options, values) { | |||
| const parseArgs = (config = { __proto__: null }) => { | |||
| const args = objectGetOwn(config, 'args') ?? getMainArgs(); | |||
| const strict = objectGetOwn(config, 'strict') ?? true; | |||
| const allowPositionals = objectGetOwn(config, 'allowPositionals') ?? !strict; | |||
There was a problem hiding this comment.
A brief comment on change in previous design/expectations.
This means parseArgs may now throw in strict:false mode for userArgs for first time. But it is opt-in and I think make sense when write it first time, and makes sense to read later.
There was a problem hiding this comment.
Yeah, I thought this was better than making it so you could have an explicit allowPositionals: false but still get positionals. The alternative is to reject allowPositionals: false in combination with strict: false, but I didn't see much value in that.
Co-authored-by: John Gee <john@ruru.gen.nz>
|
Optional: there could be a single check for |
Doing the check after parsing means any other errors will happen first, even errors which are later in the input. I prefer getting errors in the order in which the corresponding problematic things appear. |
| @@ -86,12 +87,12 @@ function getMainArgs() { | |||
| * @param {boolean} strict - show errors, from parseArgs({ strict }) | |||
There was a problem hiding this comment.
Nit: missing JSDoc for new parameter.
Something for future, not urgent. We didn't really have time to discuss this. I expect most errors for unknown options will be for typos in the option name, so the suggestion is not going to be relevant. Not harmful, but not helpful. We are going the extra mile with error messages since they may be the UX, so could perhaps have two suggestions, with a "check the spelling" type suggestion first? |
Fixes #85.
In the second commit I've updated the message for unknown options to suggest using
--. I'm not sure if this is worth doing, but I figured I'd implement it for discussion; happy to revert if it seems unhelpful.