[BetterCommand] lacks support for `allowTrailingOptions`

[indraneel12]

Premise

The upstream ArgParser supports not only usageLineLength but also allowTrailingOptions during its construction.

Problem

The current implementation of BetterCommand does not accept the allowTrailingOptions parameter. It limits my ability, as a consumer of this package, to customize the ArgParser in a direct and easy manner without relying on a workaround.

Workaround

As mentioned in the upstream documentation for this matter, I am forced to extend/compose Command yet again from BetterCommand just to override the argParser getter in a new Wrapper. This introduces an avoidable design overhead.

Suggestion

A direct approach to solve this problem, without any breaking change, could be to simply allow the parameter allowTrailingOptions alongside wrapTextColumn in the BetterCommand constructor with a default value corresponding to existing behavior.

[christerswahn]

The initialization of ArgParser is controlled by the CommandRunner of the args package. The constructor of CommandRunner doesn't provide a way to customize the creation of its ArgParser instance, so it can't be controlled from BetterCommandRunner unfortunately. This issue is probably better directed to the args package maintainers.

[indraneel12]

@christerswahn sir, I agree that the limitation for BetterCommandRunner, based on current design, stems from its superclass. However, there's potentially some misunderstanding, because this is about BetterCommand (and the solution, additionally, can be extended to BetterCommandRunner as a new feature).

Explanation

BetterCommand's parent, Command, is an abstract class with a 0-arg constructor. So, like I referenced above, they explicitly allow the approach mentioned in their docs to provide the consumers of this class the ability to customize argParser, which is effectively resolved at runtime (dynamic method resolution):

This can be overridden to change the arguments passed to the ArgParser constructor.

I have verified their code to confirm that they use _argParser only as a default and indeed rely on the getter argParser for all related processing. Additionally, this is true for not only Command but also CommandRunner.

By default, the abstract Command creates an _argParser with 0 arguments. However, as a consumer, it's possible to customize their ArgParser with 2 arguments during its construction. Therefore, they allow us to override the getter argParser which can correspond to our own private _argParser with a desirable construction.

Suggestion

This package's current design actually uses the exact approach in BetterCommand but only for usageLineLength, while the upstream API allows the customization of both usageLineLength and allowTrailingOptions. My original issue is regarding this matter, and fortunately, the solution has been working good in my local codebase.

Aside, in the case of CommandRunner, it's true that they have omitted/missed the parameter allowTrailingOptions in their constructor. However, the same solution can be applied to BetterCommandRunner as well, giving the consumers of this package an additional capability/feature.

Please correct me if I'm wrong, did I miss something? If there's anything wrong, I shall update my local codebase; or, if the issue is reopened, I shall implement this design fix/feature through a PR.