-
Notifications
You must be signed in to change notification settings - Fork 118
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
feature: defaulted functionality #211
Conversation
@juergba this feature is that simple? wow, I feel a bit silly for the complicated approach we'd left in the codebase for so long 😆 😢 @coreyfarrell mind taking a look? I believe you were a potential consumer of this functionality. |
This draft PR is not ready for review, yet. Please note:
|
ce0b2ba
to
a40322b
Compare
Quick glance this looks good. Please comment when you mark this ready for review to make sure github sends notifications. |
afa2aca
to
b5257b7
Compare
b5257b7
to
c2803e3
Compare
c2803e3
to
15f3f6d
Compare
Ok, ready for review, thanks. |
* `configuration`: the configuration loaded from the `yargs` stanza in package.json. | ||
* `newAliases`: any new aliases added via camel-case expansion: | ||
* `boolean`: `{ fooBar: true }` | ||
* `defaulted`: any new argument created by `opts.default`, no aliases included. |
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.
@juergba what's your reasoning for not including aliases? @coreyfarrell do you think you can work with this limitation?
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.
Parse.detailed()
also returns aliases
which includes all aliases, so the information would be redundant.
It's no big effort to add the aliases to defaulted
, I just need a decision.
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.
For my use it would be fine if defaulted
did not list aliases, as long as setting an alias causes the original key to be excluded from defaulted. Would you mind adding a test for this?
it('setting an alias removes associated key from defaulted', function () {
var parsed = parser.detailed('--foo abc', {
default: { kaa: 'abc' },
alias: { foo: 'kaa' }
})
parsed.argv.should.deep.equal({ '_': [], kaa: 'abc', foo: 'abc' })
parsed.defaulted.should.deep.equal({})
})
Sorry I don't have a chance to actually run this test right now but in theory it should work.
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.
Done, I added your test.
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.
Thanks @juergba!
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.
👍 thanks for this contribution, I think we should hold off on alias support until it's needed, talking with @coreyfarrell I think what we might do is introduce the feature parseDetailed
to yargs, which would have the same output as a detailed parse in yargs-parser
, for the folks that need defaulted functionality like nyc
I think this will be a good start.
|
@juergba mind taking a look at yargs/yargs#1472. |
closes #203
Parse.detailed()
returns an additional objectdefaulted
which contains any new argument created byopts.default
. This argument has not been specified by the user.defaulted
:{ foo: true }
defaulted
does not include: