Skip to content

It should be dirt simple to replace or augment CliActions #2154

Open
@KathleenDollard

Description

@KathleenDollard

CliAction is a great replacement for the old middleware pipeline. The initial vision CLI authors extending it by just implement a conditional is excellent. However, InvocationPipelin.Invoke and InvocationPipelin.InvokeAsync have significant doe and we can be fairly sure our implementation will evolve.

For example, the additions in #2147 improve the design by offering pre-actions. The code is now getting complicated and InvokeAsync is already quite complicated. All proper Invoke implementations need to run the same operations as these two methods. However, if we do this by asking CLI authors to grab the parse result and implement their own Invoke or InvokeAsync, they are forced to copy this code.

If this CLI author does not correctly implement Invoke and/or InvokeAsync, key functionality will be inconsistent with the ecosystem. Already present (assuming #2147 is merged): Environment variables will not be set and cancellation may not be done correctly.

The fix is to allow the user to supply the conditional to run at the point in InvocationPipelin.Invoke and InvocationPipelin.InvokeAsync where parseResult.CliAction.Invoke(parseResult) is called. This way the user leverages consistent ecosystem behavior now and in the future.

With this change it would remain possible to avoid grab the parse result and do whatever you want, but it would rarely be needed.

The reasons to avoid CLI author’s copying or replacing InvocationPipelin.Invoke and InvocationPipelin.InvokeAsync are:

• This code is complicated, so the user may get it wrong. This is especially true with InvokeAsync
• We are very likely to change this code, such as adding post actions. Post actions would simply not work if the programmer copied an earlier version of the InvocationPipeline methods
o While creating a post action is an advanced feature, using post actions is not
o We have these methods internal because they may change
• Failing to isolate the code we have strong opinions on from that the user has strong opinions on leaves users with code that is difficult to maintain

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions