Add Parameter to include/exclude certain files/folders when using -Path parameter set

[jdhitsolutions]

Is there a way to ignore any ps1 file that happens to be a Pester test script? It is not uncommon to having to break a few rules when constructing tests, especially when mocking.

[jdhitsolutions]

Could the script analyzer simply look for a comment like #NoAnalyze ? Or it should be simple enough to detect Pester commands like Describe and ignore the file.

[kapilmb]

cc @joeyaiello

Right now, Invoke-ScriptAnalyzer by itself doesn't have such a capability. However, a workaround would be to filter out the *.tests.ps1 files and pipe the remaining files to Invoke-ScriptAnalyzer. For example

Get-ChildItem -Path <targetPath> -Exclude "*.tests.ps1" | Invoke-ScriptAnalyzer

Having said that, I think this would be a good feature to have in the settings file.

[jdhitsolutions]

And it isn't merely Pester tests. I often use a scratch.ps1 file as a temporary dumping ground or a place to hold snippets of code I'm working on. It is a bit of a nuisance to have that file constantly checked for rules.

[kjacobsen]

What about having a -ExcludeTestFiles parameter?

Except with a better name.

[RobFaie]

Why should your tests be held to lower standards than the rest of your code?

[4c74356b41]

because they are tests, what kind of question is that, why don't you write tests for tests? why should you have lower standards for test than the rest of your code?

[kjacobsen]

Good point @RobFaie, only issue is that some times Pester syntax can trigger false positives.

[gaelcolas]

I'm having the same problem, especially with the PowerShell Extension (but it's not a PS Extension problem).

I'd like to exclude some folders and files, that might be present in my workspace, but I don't want them to be analyzed.

"As a vscode extension user, I need a way in the Analyzer Settings file to exclude some folders, such as my "output/RequiredModules" folder, my "tests" folder as requested by @jdhitsolutions or anything that might be present in my folder without being part of the source of the current project".

Although it should not be automatic, you can think of most things in .gitignore to fall into that category, but it's for the user to chose and configure per-repo.

/cc @bergmeister as we discussed that on slack
Please rename this issue as it's not just pester tests but exclude any file and folder in PSSA config.
I know the vscode extension may be using -ScriptDefinition and not -Script, but having an exclude in settings would open the door to the same behaviour within and outside the vscode PowerShell extension.

[bergmeister]

@gaelcolas For settings support, there is issue #1230
The way the extension works, I'd still say it is something to be implemented in the extension for your use case. Because people edit their code without always saving the file, the extension needs to use the -ScriptDefinition parameter set to analyse the current in memory text. Do you agree @TylerLeonhardt ?
This and the other issue is for cmdlet/setting files options, which is a different use case.

[TylerLeonhardt]

Yeah. The extension would need an exclusion list. Feel free to open an issue in https://github.com/PowerShell/vscode-powershell

[mikaello]

However, a workaround would be to filter out the *.tests.ps1 files and pipe the remaining files to Invoke-ScriptAnalyzer. For example

Get-ChildItem -Path <targetPath> -Exclude "*.tests.ps1" | Invoke-ScriptAnalyzer

A downside of this workaround is that when combined with -EnableExit, only the exit code of the last file is considered (i.e., if the 10 first files have violations, and the last file analysed have none, the final exit code will be 0), this makes it impossible to use in a CI/CD context.

If Invoke-ScriptAnalyzer would support a comma separated list of files as input, a workaround for this problem could have been:

(Get-ChildItem -Path <targetPath> -Exclude "*.tests.ps1") -join "," | Invoke-ScriptAnalyzer -EnableExit

But I couldn't get that to work.

[fourpastmidnight]

The idea of this issue is excellent. I have a use-case where I have another module that is a dependency of the module I'm writing and which I'm including in "source form" as part of the build output of the module under test. (I wrote both modules--and currently, I have a "distribution challenge" which is causing me to include this dependent module in "source form" within the build output.)

The issue is that the "dependent module" is independently built/linted/tested itself, so I don't want or need to repeat analysis on this essentially "external dependency" that just happens to be in my project output as part of the "build" process. So the ability to ignore/exclude paths qualified by the -Path parameter value would be fantastic. It would save time, and, let's say I was including a true external module dependency in source form in my output folder--I don't own that source, and so I wouldn't want my lint report to contain errors/warnings for something I don't own. This is even more important when the PSScriptAnalyzer settings are "treat warnings as errors".

[Pxtl]

Yeah. The extension would need an exclusion list. Feel free to open an issue in https://github.com/PowerShell/vscode-powershell

They said to open an issue here.

PowerShell/vscode-powershell#3048 (comment)

[JustinGrote]

PowerShell Extension contributor (and more accurately PSES for this issue) here, @TylerLeonhardt has moved on to much bigger and better things since he wrote that 5 years ago :)

The extension's philosophy is to do things downstream if possible and effectively just be a "UI" as much as possible, so that all editors can benefit and not just ones that use the LSP. We do use ScriptDefinition to do static analysis in-flight for unsaved editors today, but we also know the original path of the file.

In an ideal world (for us), includes/excludes could be defined as part of the -Settings parameter (either supplied directly or via .psd1) and merged with whatever is specified in -Path (with excludes taking precedence), and then there would be either a -DryRun, a .NET method on the analysis engine, or something that would list what files would be analyzed quickly without performing an actual analysis yet. If we had that, then we could build logic around that to only analyze files that show up in the dry-run list. This way our logic of what constitutes an include/exclude does not conflict with whatever engine is used to determine that inside ScriptAnalyzer

We could also implement all of this logic in PSES via settings, but it seems to make more sense to implement it first in core ScriptAnalyzer so non-PSES users can benefit (e.g. Github Actions and whatnot).

@bergmeister your thoughts?
CC @andyleejordan for thoughts/ideas as well