Add UseSingleValueFromPipelineParameter Rule

[liamjpeters]

PR Summary

Adds a new rule, UseSingleValueFromPipelineParameter, which flags when multiple parameters in the same parameter set have ValueFromPipeline set to true.

When running something like:

function Test-ValueFromPipeline {
    [CmdletBinding()]
    param (
        [Parameter(ValueFromPipeline)]
        [string]
        $Parameter1,
        [Parameter(ValueFromPipeline)]
        [string]
        $Parameter2
    )
    process {
        "Parameter1: $Parameter1!"
        "Parameter2: $Parameter2!"
    }
}

"Value1" | Test-ValueFromPipeline

I don't get any kind of error or warning, which I was surprised by.

Consistent behaviour across both 5.1 and 7.4.11.

Multiple parameters accepting pipeline input by value doesn't make sense (to me at least - maybe I'm missing a use-case?).

The above outputs:

Parameter1: Value1!
Parameter2: Value1!

Both parameters get the pipeline input bound.

Parameter [Parameter2] PIPELINE INPUT ValueFromPipeline NO COERCION
BIND arg [Value1] to parameter [Parameter2]
    Executing DATA GENERATION metadata: [System.Management.Automation.ArgumentTypeConverterAttribute]
        result returned from DATA GENERATION: Value1
    BIND arg [Value1] to param [Parameter2] SUCCESSFUL
Parameter [Parameter1] PIPELINE INPUT ValueFromPipeline NO COERCION
BIND arg [Value1] to parameter [Parameter1]
    Executing DATA GENERATION metadata: [System.Management.Automation.ArgumentTypeConverterAttribute]
        result returned from DATA GENERATION: Value1
    BIND arg [Value1] to param [Parameter1] SUCCESSFUL

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .cs, .ps1 and .psm1 files have the correct copyright header
• Make sure you've added a new test if existing tests do not effectively test the code changed and/or updated documentation
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

[liamjpeters]

Bodging a built version of this into VSCode, I think it makes sense to flag each parameter attributes so they all get a yellow squiggly. That said, if there's a way to emit a single DiagnosticRecord that has multiple extents, I'm happy to change it.

[andyleejordan]

Multiple parameters accepting pipeline input by value doesn't make sense (to me at least - maybe I'm missing a use-case?).

You're right that most of the time someone does this, it's probably a mistake. But it is valid and there's a small use case of switching parameter sets based on the type of value received over the pipeline. So we can accept this as an optional rule, but it cannot be on by default.

[andyleejordan]

Can you make this rule not enabled by default?