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

• [x] PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• [x] Summarized changes
• [x] Change is not breaking
• [x] Make sure all .cs, .ps1 and .psm1 files have the correct copyright header
• [x] Make sure you've added a new test if existing tests do not effectively test the code changed and/or updated documentation
• [x] 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.

[liamjpeters]

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.

Thanks so much for looking at this Andy 😀

I don't follow currently and I'm keen to. If you've the time to explain that use-case, I'd really appreciate that. If not, don't worry I'll get this changed to optional as you suggest.

---

The rule checks that, at most, one parameter per set accepts pipeline input by value (my comment ommited "set"). So, if you're changing parameter sets based on the pipeline input - that's fine, you'd still only be accepting value binding on one parameter in that set?

function Test-ValueFromPipeline {
    [CmdletBinding()]
    param (
        [Parameter(ParameterSetName = 'One', ValueFromPipeline)]
        [string]
        $Parameter1,
        [Parameter(ParameterSetName = 'Two', ValueFromPipeline)]
        [int]
        $Parameter2
    )
    process {
        "$($PSCmdlet.ParameterSetName) was used."
        "Parameter1: $Parameter1!"
        "Parameter2: $Parameter2!"
    }
}

'8' | Test-ValueFromPipeline

# One was used.
# Parameter1: 8!
# Parameter2: 0!

8 | Test-ValueFromPipeline

# Two was used.
# Parameter1: !
# Parameter2: 8!

When multiple parameters accept pipeline input by value - binding without and with type coercion is attempted for each. If the binding succeeds for multiple parameters then you have the same data bound to multiple parameters? I guess one parameter could be a string and another could be an int, bound by coercion if the string is a valid integer?

Is the use-case you're talking about when coercion for one such type would fail? e.g. An int and a Process

function Test-ValueFromPipeline {
    [CmdletBinding()]
    param (
        [Parameter(ValueFromPipeline)]
        [System.Diagnostics.Process]
        $Parameter1,
        [Parameter(ValueFromPipeline)]
        [int]
        $Parameter2
    )
    process {
        "Parameter1: $($Parameter1.Name)!"
        "Parameter2: $Parameter2!"
    }
}

Get-Process -Name 'Code' | Select -First 1 | Test-ValueFromPipeline

# Parameter1: Code!
# Parameter2: 0!

1990 | Test-ValueFromPipeline

# Parameter1: !
# Parameter2: 1990!

You'd then make some check about $Parameter1 having a value and go from there with whatever logic?

If that's the case, why would the use of parameter sets not be encouraged? The 32 set limit? Complexity?

[andyleejordan]

@SeeminglyScience has the explanation (I was relaying it from a triage call).