feat: apply default builder to command() and apply fail() handlers globally #583
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses this TODO from #545:
When implementing this, I discovered it was necessary to either (a) change the expectations of some tests to move a top-level
.fail()
handler to a command-specific one or (b) start applying.fail()
handlers globally. I opted for the latter due to conversation in #539.Therefore, this PR solves 2 main problems:
Do not require a command to specify a builder in order for validation to apply
Prior to this, code such as
.command('hi').demand('name').global('name')
would not enforce the globally required--name
option whenhi
is given on the command line, which has been outlined here, because "running" a command without a builder would actually bypass a reset, reparse, and subsequent validation.This PR changes that so a command like
.command('hi')
is now equivalent to a command like.command('hi', '', {})
.Note that I have an alternative implementation that applies validation to builder-less commands without the reset or reparse (and means options do not have to be global to be, e.g., required), but I prefer the approach of this PR since it (i) causes all commands to be treated equally as running within a "command context" and (ii) satisfies the previous TODO (and whatever thought process/concerns went with it).
Accepting this PR means options must be explicitly global (or command-specific) in order to apply to a command.
Allow a top-level
.fail()
handler to handle errors that occur during command executionAs previously discussed in Better error reporting for subcommands #539.
This also means that multiple fail handlers at different "command depths" will all be called in depth-first, reverse order. For example, the following code:
Would produce this:
Note that both of these are BREAKING CHANGES.