refactor!: rework results to remove redundant flags property and store value true for boolean options
#83
Conversation
| - Does `--no-foo` coerce to `--foo=false`? For all options? Only boolean options? | ||
| - no, it sets `{values:{'no-foo': true}}` |
There was a problem hiding this comment.
unrelated to this PR, but it would be nice to have parseArgs handle "what if i do --foo --no-foo" for me
There was a problem hiding this comment.
I note that's something you could trivially build on top of parseArgs if it reports indexes of arguments (#84).
Co-authored-by: Jordan Harband <ljharb@gmail.com>
…ub.com:shadowspawn/parseargs into feature/refactor-results-leaner-meaner-cleaner
|
Got a couple of 👍 (thanks) but still looking for an approving review before can merge. |
I worked through some core use cases in #38 using various patterns for the results, and didn't find any holes. (At the time the approach used in this PR was just included for interest!) |
|
@shadowspawn I think this is ready to go IMO, except it appears to have one failing test. |
|
I'll need to add |
👍 if you're feeling good about the PR, I can do my best to merge early this week and get our current state synced with the Node.js PR. |
|
Ready, barring more changes landing on main first. 😄 |
Leaner, meaner, cleaner!
See #70 for longer description (deleting
flagsin #70 (comment)). See #80 for previous proposal to renameflagsrather than delete, and this PR built on that.The big change in this PR is removing the
flagsproperty in the results.flagsis not encoding any additional information, and is not adding much. The lack of a compelling use case has made renaming it difficult!In parse results:
flagstrueinvaluesfor boolean options (rather thanundefined)In README, a number of minor fixes after reading through examples carefully:
--description to match current implementation