Accept settings as a hashtable, not only a file path - #20
Merged
Merged
Conversation
Invoke-ScriptAnalyzer types its -Settings as object and has always taken a hashtable; this module narrowed it to [String]. A caller assembling settings at run time therefore had to serialize them to a file first, which meant writing to a temp path, cleaning it up, and keeping the write collision-free between processes -- all to satisfy a constraint that was never PSScriptAnalyzer's. The workaround already passed hashtables to Invoke-ScriptAnalyzer internally, so only the parameter types and the one Import-PowerShellDataFile stood in the way. - Widen -Settings to [Object] on Invoke-PSModuleAnalyzer and the private casing workaround - Import the data file only when the value is a string - Copy the levels the split-casing run edits, so a caller's hashtable is left alone - Bump to 4.1.0; a string still binds, so nothing existing changes
SummarySummary
Coveragesrc/Private - 95%
src/Public - 88.8%
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Invoke-ScriptAnalyzerdeclarespublic object Settingsand has always accepted a hashtable. Thismodule narrowed it to
[String], so a caller assembling settings at run time had to serialize them toa file first — writing to a temp path, cleaning it up, and keeping the write collision-free between
processes, all to satisfy a constraint that was never PSScriptAnalyzer's.
The casing workaround was already passing hashtables to
Invoke-ScriptAnalyzerinternally(
$recursiveAnalyzerArguments.Settings = $settingsData, and again for$casingSettings), so the onlythings standing in the way were the two parameter types and one
Import-PowerShellDataFile.-Settingsto[Object]onInvoke-PSModuleAnalyzerand the private casing workaroundset
Rules.PSUseCorrectCasing.Enable = $falsein place, which was safe only because the valuealways came from a fresh
Import-PowerShellDataFileTwo tests added: a hashtable run end to end, and a guard that the caller''s copy is unmodified.
74 tests pass;
srcis analyzer-clean.