René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"🚀[Feature]: Isolate build, test and document process","articleBody":"### Description\n\nNeed to have an isolated build process so that no assemblies clobber others and no modules are loaded to confuse platyPS.\n\nYou can create an isolated runspace from within PowerShell itself using the .NET API. This lets you build your module in a separate session state—essentially an “isolated runtime” inside your current process—without the modules or assemblies imported in your parent session.\n\nHowever, note that runspace isolation isn’t as complete as a new process (for example, already-loaded assemblies may still be visible), but it does allow you to start with a fresh session state and avoid the auto-loaded modules and functions from your current session.\n\nBelow is an example of how you can create an isolated runspace with a clean initial session state, dot-source only your build script, run your build function, and then clean up the runspace:\n\n```powershell\n# Define the build logic as a ScriptBlock\n\n$buildScript = {\n    # Disable module autoloading\n    $PSModuleAutoloadingPreference = 'None'\n    $var = Get-Date -Format \"yyyy-MM-dd-HH-mm-ss\"\n    # Blank out PSModulePath to prevent any module auto-loading from default locations\n    New-Item -Path \"C:\\Repos\\$var\" -ItemType Directory\n}\n\n# Create a new initial session state (only core commands are loaded)\n$iss = [System.Management.Automation.Runspaces.InitialSessionState]::CreateDefault()\n\n# Create and open a new runspace with this session state\n$runspace = [runspacefactory]::CreateRunspace($iss)\n$runspace.Open()\n\n# Create a new PowerShell instance and assign it the isolated runspace\n$ps = [PowerShell]::Create()\n$ps.Runspace = $runspace\n\n# Add the build script from the ScriptBlock by converting it to a string\n$ps.AddScript($buildScript.ToString()) | Out-Null\n\n# Invoke the script in the isolated runspace\n$results = $ps.Invoke()\n$results\n# Check for any errors during execution\nif ($ps.HadErrors) {\n    Write-Error 'Errors occurred in the isolated build runspace:'\n    $ps.Streams.Error | ForEach-Object { Write-Error $_.ToString() }\n}\n\n# Clean up the runspace and PowerShell instance\n$ps.Dispose()\n$runspace.Close()\n$runspace.Dispose()\n```\n\n### Explanation\n\n- **InitialSessionState**: By using `[InitialSessionState]::CreateDefault()`, you start with a clean slate containing only the core commands and providers. Modules or functions imported in your parent session aren’t carried over.\n  \n- **Restricting PSModulePath**: In the script block (or by modifying the session state), you can clear or restrict `$env:PSModulePath` so that only modules you explicitly load (like your build script) are available.\n\n- **[PowerShell]::Create()**: This creates a new PowerShell instance that runs in the separate runspace. Commands added to this instance run in isolation from the current session.\n\n- **Dot-Sourcing Your Build Script**: The script block dot-sources `build-module.ps1` so that only the necessary build functions are loaded. Then, `Build-MyModule` is called to build and output your module artifact.\n\n- **Cleanup**: Disposing of the runspace and PowerShell instance cleans up any resources used during the isolated build process.\n\nThis approach keeps your build operations isolated within the same process, allowing you to avoid conflicts with preloaded modules and to build your module without interference. If you need complete isolation (for example, if there’s concern about already loaded assemblies), you might consider spawning a new process using `pwsh -NoProfile` as an alternative.","author":{"url":"https://github.com/MariusStorhaug","@type":"Person","name":"MariusStorhaug"},"datePublished":"2025-02-24T17:47:25.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/148/Process-PSModule/issues/148"}