Users can inadvertently blow up psake with name conflicts #145
Description
Psake currently dot-sources a lot of user code into its own internal scope (properties blocks, etc). This can be dangerous, as users may wind up overwriting the same variable names used by Psake internally. For example, a quick repro:
Properties {
$psake = $null
}
task default -depends IBrokeIt
task IBrokeIt {
Write-Host 'This will never output'
}
<#
Output:
Invoke-psake : The property 'build_success' cannot be found on this object. Verify that the property exists and can be set.
At line:1 char:1
+ Invoke-psake .\testing.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Invoke-psake], RuntimeException
+ FullyQualifiedErrorId : PropertyNotFound,Invoke-psake
#>Pester had the same problem prior to v3.0. It can be fixed, but involves a fair bit of jumping back and forth between script and module scopes (and keeping track of what's visible from each).