Adds whitespace around operators with whitespaceAroundOperator set to false in some cases

[o-l-a-v]

Prerequisites

• I have written a descriptive issue title.
• I have searched all open and closed issues to ensure it has not already been reported.
• I have read the troubleshooting guide.
• I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
• I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
• If this is a security issue, I have read the security issue reporting guidance.

Summary

vscode-powershell inserts a space before an operator in some cases, even with:

"powershell.codeFormatting.whitespaceAroundOperator": false

PowerShell Version

> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.4.1
PSEdition                      Core
GitCommitId                    7.4.1
OS                             Microsoft Windows 10.0.22631
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

> $Host


Name             : Visual Studio Code Host
Version          : 2024.0.0
InstanceId       : 140baa93-df7a-407d-81bb-095443b84275
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : nb-NO
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace

Visual Studio Code Version

1.87.0
019f4d1419fbc8219a181fab7892ebccf7ee29a2
x64

Extension Version

[email protected]

Steps to Reproduce

Get-Process | `
    Sort-Object -Property @{'Expression'={$_.'Name'}} | `
    Select-Object -Property @{'Name'='ProcessName';'Expression'={$_.'Name'}}, 'Id'

What it ends up looking like:

Get-Process | `
    Sort-Object -Property @{'Expression' ={$_.'Name'}} | `
    Select-Object -Property @{'Name'='ProcessName';'Expression'={$_.'Name'}}, 'Id'

Notice it only adds a whitespace after 'Expression' in Sort-Object -Property.

Visuals

No response

Logs

No response

[liamjpeters]

This looks to be being caused by rule PSAlignAssignmentStatement, not PSUseConsistentWhitespace.

The simplest case where I can reproduce this is:

Invoke-Formatter -ScriptDefinition "@{'Key'='Value'}" -Settings @{
    Rules = @{
        PSAlignAssignmentStatement = @{
            Enable = $true
            CheckHashtable = $true
        }
    }
}

Results in:

@{'Key' ='Value'}

The rule seems to be opinionated about there being a single space after the key name when it does it's alignment.

The rule has some logic to check if the hashtable is on multiple lines and, if not, should not check it for violations. This logic does not take into account the case where the hashtable has a single key-value pair. The function HasPropertiesOnSeparateLines returns true in this case.

This is why in the test case @o-l-a-v highlighted, the property hashtable passed to Sort-Object is formatted (It has a single key-value pair), whereas the property hashtable passed to Select-Object is not formatted (it has 2 key-value pairs on the same line).

So:

Invoke-Formatter -ScriptDefinition "@{'Key'='Value';'key2'='value2'}" -Settings @{
    Rules = @{
        PSAlignAssignmentStatement = @{
            Enable = $true
            CheckHashtable = $true
        }
    }
}

Results in:

@{'Key'='Value';'key2'='value2'}

@o-l-a-v - If you set the below, you won't see this behaviour - you'll also not get nice alignment of your hashtable property-value pairs though 😅.

"powershell.codeFormatting.alignPropertyValuePairs": false

I can do a small PR to add a check to see if there's just the 1 key-value pair, and if so, not to check it for violations - that should resolve this - assuming that's the desired behaviour.

[o-l-a-v]

Great reasearch @liamjpeters. Your described behavior for a fix is what I'd want.

[bergmeister]

Great details. Happy to support you in making a pull request, from my own experience I know though it's hard to write generic code without special cases like that and fixing them without breaking something else, we have got good test coverage though.