EditorSyntax VS PSScriptAnalyzer

Serious answer: It depends on how much you care about it. At one point I used this WIP rewrite of the grammar: https://github.com/PowerShell/EditorSyntax/pull/156 + a custom theme to get it exactly how I want it but it was a bit of a pain to maintain across updates, new computers, etc. These days I just do most of my editing in ISE and only use VS code for minor tweaks.

There is a PR that mostly solves the inaccuracies here: https://github.com/PowerShell/EditorSyntax/pull/156 but it has been WIP since 2019 with no sign of him finishing it in the near future. I don't blame him because it's a ton of work and semantic highlighting sort of made it irrelevant but it does leave us without an official editor that can handle the PS6+ syntax.

This is the grammar I'm using: https://github.com/PowerShell/EditorSyntax/pull/156 except I'm using the slightly modified version that is mentioned in the comments to properly highlight commands without the approved verb-noun syntax.

The beginning of the chaos was this commit https://github.com/PowerShell/EditorSyntax/commit/0cf060e9e0095e8e2565a3496d3909067b49fd90 which you'll notice contains no regex changes. It was things like changing the scope of $ from keyword.other.variable.definition.powershell to punctuation.definition.variable.powershell.

I am looking to build a custom profile for a ws2019 with ps 7.2 + to use to check my scripts, i have tried using the compat collector https://github.com/PowerShell/PSScriptAnalyzer/tree/development/PSCompatibilityCollector and running the build.ps1 script there but I do not see an output for my commands and the script text doesn't provide much clarify to me at least.

PSScriptAnalyze is a static code analysis tool that checks PowerShell scripts for best practices and potential security issues. It is available on GitHub and can be installed as a module in PowerShell. https://github.com/PowerShell/PSScriptAnalyzer

PSScriptAnalyzer is a static code checker for PowerShell modules and scripts. Runs a set of rules that test the quality of PowerShell code against best practice, then warns about potential code defects and suggests potential solutions. xXxLinuxUserxXx likes this linter "to get unified codestyle in the scripts."

Not a windows admin and more like a programmer but i would suggest to use some linter (https://github.com/PowerShell/PSScriptAnalyzer) to get unified codestyle in the scripts :)

It’s best practice to keep $null on the left side of comparisons https://github.com/PowerShell/PSScriptAnalyzer/blob/development/RuleDocumentation/PossibleIncorrectComparisonWithNull.md

This one is a real problem. When I reference a type which is defined in another file in a class, I get an error in my vscode. the class works but the PSScriptAnalyzer doesn't know that the type is imported. I found this github issue which is about supressing the issue, I tried that and couldnt get it to work but I'd rather that it just recognized the type from the other file https://github.com/PowerShell/PSScriptAnalyzer/issues/1041

I would definer not autoformat on save with bugs such was this still outstanding: https://github.com/PowerShell/PSScriptAnalyzer/issues/1580

That's some sloppy code. Wmic is deprecated. You shouldn't put unencrypted passwords in scripts. You shouldn't use write-host anymore. $null goes in front, etc. Try using https://github.com/PowerShell/PSScriptAnalyzer to ensure decent code. Also write code in vscode. Also read https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1

I discovered the Invoke-Build build system, PSScriptAnalyzer for linting, and Pester for testing/mocking. I wrote a GitLab CI/CD pipeline that takes advantage of all of this to push releases to our company's PSRepo. I also discovered the Plaster template system for scaffolding new projects, and created a custom company template for standardizing our repo structures.