'PROCESS' is implicitly aliasing 'Get-PROCESS'

[RichMath]

Using version 1.18.3:
In a .psm1 file using a "process" block, this diagnostic is produced:

'PROCESS' is implicitly aliasing 'Get-PROCESS' because it
is missing the 'Get-' prefix. This can introduce possible
problems and make scripts hard to maintain. Please consider
changing command to its full name.

[RobertKlohr]

I'm running into the same issue. I am working on a project where I am coding multiple advanced functions as separate .ps1 files. I have not isolated the triggering event but I most often notice it after I save a the file I'll see the number of errors listed go from zero to some number greater than zero. I now first go look at the process{} block of the function and I will find that it has been renamed to Get-Process.

Sometimes when I go to fix the change it will revert back as I am typing. In these cases I need to close the editor window and re-open it and then make the correction.

PSScriptAnalyzer 1.18.3
VSCODE 1.41.1
PowerShell Preview 2020.1.0

I experienced the same behavior when I switched to PowerShell stable version and disabled all my extensions.

[SydneyhSmith]

@RichMath thanks for opening this issue! The AST version comes from PowerShell so it would be helpful if you and @rjkgithub could please provide $PSVersionTable

A repro script where this issue is observed would also be very helpful. Thanks!

[bergmeister]

I cannot reproduce using PowerShell 5.1 or 7 on Windows using the following example. Please specify the example that triggers it for you and supply more info about your info such as PS and OS version

function Get-Noun {

    process {
        
    }

}

[RichMath]

Import-Cut.txt

@RichMath thanks for opening this issue! The AST version comes from PowerShell so it would be helpful if you and @rjkgithub could please provide $PSVersionTable
A repro script where this issue is observed would also be very helpful. Thanks!

A script that exhibits this problem is attached to this reply.

Windows version:
Edition: Windows 10 Pro
Version: 1903
OS Build: 18362.592

PS C:\Users\richm> $PSVersionTable

Name Value

---

PSVersion 5.1.18362.145
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.18362.145
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

[RichMath]

I cannot reproduce using PowerShell 5.1 or 7 on Windows using the following example. Please specify the example that triggers it for you and supply more info about your info such as PS and OS version
function Get-Noun {

process {
    
}

}

I included all the above in my reply to SydneyhSmith.

[bergmeister]

@RichMath Using your supplied Import-Cut.txt in your comment (and renaming it to .psm1), I still cannot reproduce using either PowerShell 5.1 or 7. My OS is Windows 10 Pro 1909, which can be considered equivalent to your PowerShell version as far as I am aware. Since Windows 1903, the version of .Net (on which PowerShell depends on), is 4.8, therefore there should not be a difference between Windows 10 1903 and 1909 given that the PowerShell team only distributes security relates patches to PowerShell 5.1. My version number is 5.1.18362.628 and the difference in the last number should only be because it came from a different Windows build since Windows PowerShell ships as part of Windows

Can you please run Invoke-ScriptAnalyzer Path $PathToFile -Verbose using both a normal PowerShell console and using the PowerShell integrated console in VS-Code please and supply the output of it?
The same for the output of (get-command invoke-scriptanalyzer).module.path as well please.

[RichMath]

@RichMath Using your supplied Import-Cut.txt in your comment (and renaming it to .psm1), I still cannot reproduce using either PowerShell 5.1 or 7. My OS is Windows 10 Pro 1909, which can be considered equivalent to your PowerShell version as far as I am aware. Since Windows 1903, the version of .Net (on which PowerShell depends on), is 4.8, therefore there should not be a difference between Windows 10 1903 and 1909 given that the PowerShell team only distributes security relates patches to PowerShell 5.1. My version number is 5.1.18362.628 and the difference in the last number should only be because it came from a different Windows build since Windows PowerShell ships as part of Windows
Can you please run Invoke-ScriptAnalyzer Path $PathToFile -Verbose using both a normal PowerShell console and using the PowerShell integrated console in VS-Code please and supply the output of it?
The same for the output of (get-command invoke-scriptanalyzer).module.path as well please.

I think I found the problem. I wasn't able to repro the problem today . . . but I'd made a change to the code last night. Before that change the two "enums" in the script were placed before the "begin{" block. PSScriptAnalyzer did NOT flag that as an error, but Powershell did. The change I made was to move the "begin {" to include those two enums, and that made the "Process" problem disappear.
I've attached the original PSM1 file (that produced the error) and the output of Invoke-ScriptAnalyzer with the -Verbose switch.
If you need more information, please let me know.

Import-Cut.psm1.TXT
PsScriptAnalyzerOutput.txt

[bergmeister]

Thanks, I can reproduce now with your new example (using PowerShell Core, not a PowerShell version issue). A much simpler repro is (and the cause seems to be the enum)

function Import-Cut{
	[CmdletBinding()]
	param()

    enum foo {
        bar
        baz
    }

	process {

	}
}

Although the enum is the cause of it, the implicit Get- aliasing applies to all commands, except to Get-Process, because of process being a keyword, therefore I think just excluding Get-Process in the rule would be a good solution but I am still interested to find out why the parser sees the process block as a CommandAst.
I definitely recommend you to move the enum definition outside of the function definition or into the begin block as you did. It does not seem to cause an error when parsing the script but the parsing result is definitely corrupt, a deficiency of the parser to not spot the invalid syntax I think.

To conclude, the red herring caused by Invoke-scriptanalyzer -scriptdefinition 'process' should be fixed but the issue in the presented script was invalid syntax but the parser did throw an error at parse time unfortunately (at least at runtime as you said)