-
Notifications
You must be signed in to change notification settings - Fork 17
Open
Description
It would be good once PSScriptAnalyzer reaches a level of maturity that it can be enabled by default, rather than currently where it has to be explicitly enabled.
Before this can happen I see the following needing to be done:
- Stop passing sut and TestSettings variables into Pester's module context using a global variable
- Check if Pester's PrivateData is in use and if it isn't then pass it in that way or if it is but can be extended (if its a hashtable) then do that
- This module & it's PrivateData would likely be inaccessible as Pester won't have it in scope, if possible it would be preferable to avoid interfering with Pester's internal state
- Report all violations of a rule rather than just the first instance as know them all but we only report the first, resulting in a fail->fix->still fails->fix cycle which is tedious
- Potentially aggregating the violations (multiple Should's, or similar to .NET's AggregateException)
- Don't display a specific rule violation message but the generic version (don't use aliases rather than dont use the % alias) and part of the message is the number of failures, the same message can be used for passing rules just with the failure count reading 0. The stacktrace field could possibly be used to store the details for each instance where the rule is violated
- Identify a suitable list of rule exclusions to have as a default to avoid the functionality being seen as a hindrance instead of being beneficial
- Determine any side effects of enabling it by default
- Adding PSScriptAnalyzer as a nested module to the psd1 file
- Determine if WMF5/PS5 is actually required or if it is only needed for Install-Module functionality