You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently building a CLI using oclif and have another special use case I am not sure how to implement:
(In my understanding this issue is about the exact same code as #270, but represents another use case. I am writing it down, just as additional input)
I have 2 arguments. The first defines a "platform", and the second the "action" that should be executed. The list of actions depends on the platform (with our without overlap between the platforms, not sure yet). Right now I have added all the available actions for all platforms to the options of that argument, and use parse or code in run itself to validate that the chosen action is actually valid for that platform.
Could there be a concept of options that depend on the value of another argument? Would that make sense in the docs?
A workaround here would be to actually use 2 different subcommands, one for each platform instead of both using the same command and then branching for the platform in the code. But the command really shares all the logic besides this argument handling stuff, so I am hesitant to do that (and the : for subcommands might also play a role).
The text was updated successfully, but these errors were encountered:
@mdonnalley It would be nice to include some context/description on why the issue is being closed (if it was completed, then when/where it was completed; if it's 'not planned' then more of an explanation of why it's not going to happen). This current process of 'close a huge pile of issues' with no context is generally considered pretty 'hostile'/'disrespectful' (for lack of a better term) to open source/collaboration/etc.
I am currently building a CLI using
oclif
and have another special use case I am not sure how to implement:(In my understanding this issue is about the exact same code as #270, but represents another use case. I am writing it down, just as additional input)
I have 2 arguments. The first defines a "platform", and the second the "action" that should be executed. The list of actions depends on the platform (with our without overlap between the platforms, not sure yet). Right now I have added all the available actions for all platforms to the
options
of that argument, and useparse
or code inrun
itself to validate that the chosen action is actually valid for that platform.Could there be a concept of options that depend on the value of another argument? Would that make sense in the docs?
A workaround here would be to actually use 2 different subcommands, one for each platform instead of both using the same command and then branching for the platform in the code. But the command really shares all the logic besides this argument handling stuff, so I am hesitant to do that (and the
:
for subcommands might also play a role).The text was updated successfully, but these errors were encountered: