-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Pull request catalog by @aweebit #1964
Comments
In general, if you keep the Pull Requests independent then they will be dealt with from oldest to newest. This issue will be useful for working through the older intertwined ones. But note also, you are opening Pull Requests far faster than I can review them. |
Good news: I think I am going to run out of ideas in a day or two :) |
Note mainly for myself
|
I will be very busy during the next few days, gonna reply to new comments on the PRs when I am free again. |
Thanks for update, no problem. |
Down to just a few open PRs so an overview of the backlog is no longer needed. |
I try my best to keep this PR list sorted by the importance of the changes (and also how easy they are to accept) while at the same time keeping it structured well.
The list was originally placed in a random comment (#1919 (comment)), which I didn't like. I hope it's okay that I've moved it to an issue.
Patches
ChangeLog type:
Fixed
preSubcommand
hooks on help command #1956Enhancements / changes in behavior
ChangeLog type:
Added
/Changed
Changes in behavior fixing open issues
Misc
readonly
mode) #1970.strictOptionalOptionArguments()
for POSIX-style handling of options with optional option-arguments #1951 (fixes #1901, quite robust and thus ready for review in my opinion, only tests missing)Pure refactors and other changes of low importance
.addOption()
responsible for storing the default value #1961On hold
Closed but might need reconsideration or a new proposal
Misc
.description()
: do not set command description ifundefined
is provided in the first parameter #1966 (a subset of #1967 from right above)Help.visibleOptions()
#1935 (might want to decouple from #1929)createOption()
inhelpOption()
to support custom option flag extraction (+ various improvements) #1929 (a subset of #1934 and #1935 from right above)copyInheritedSettings()
recursive #1922parse()
/parseAsync()
#1919 (partially fixes #1916 and a lot of older issues).addCommand()
#1941opts()
from unsafely exposing a private object and expose a proxy instead #1921With warnings about presumably wrong library usage
.parse()
#1940 (partially fixes #1916).command()
#1938 (includes an arguably questionable enhancement to parent handling, so might require more time to think about than the previous PR, but the warning is very, very, VERY useful) (partially fixes #1916).suppressWarnings()
for warnings in #1915 #1931 #1938 #1940 #1955 (a reasonable addition since all warnings introduced in the PRs above are for usage patterns that are not always wrong, just often connected with a developer mistake)Pure refactors and other changes of low importance
allowUnknownOption
in.parseOptions()
#1946 (discussion finished in #1945, but reiterated in #1947 (comment))addHelpCommand()
properly #1927Changes to core project principles
Issues that might need a PR
postParse
hooks #1976Command
instance to argParsers #1968passThroughOptions
and unknown option handling #1936 (awaiting feedback)passThroughOptions
being a superset ofenablePositionalOptions
#1947 (awaiting feedback)@api
JSDoc tag #1949Completed
Help.wrap()
#1904chainArgParserCalls()
for configuration. Additionally await thenable implicit and default option values and thenable default argument values #1915storeOptionsAsProperties()
after setting option values #1928getCommandAndParents()
intoCommand._getCommandAndAncestors()
and use consistently #1939.executableDir()
return type #1965Option.env()
behave as a getter when called with no arguments #1971The text was updated successfully, but these errors were encountered: