Initialize-DeveloperMachine
0.1.2
Bootstrap a Windows developer machine: relocate caches off C:, install winget tools, set up WSL + Docker Desktop. Modular tasks, idempotent, dry-run support.
Minimum PowerShell version
5.1
Installation Options
Owners
Copyright
(c) gonace. All rights reserved.
Package Details
Author(s)
- gonace
Tags
Developer Bootstrap Windows WSL DockerDesktop winget Junction Cache NuGet npm
Functions
PSEditions
Dependencies
This module has no dependencies.
Release Notes
Patch release. All three changes are from real-world install of `v0.1.1` finding rough edges that shipped accidentally.
```powershell
Update-Module Initialize-DeveloperMachine -Scope CurrentUser
# or, fresh install:
# Install-Module Initialize-DeveloperMachine -RequiredVersion 0.1.2 -Scope CurrentUser
```
## 🐛 Fixes
- **Interactive scaffold now actually fires for `Install-Module` users.** `v0.1.1` shipped the bundled `Initialize-DeveloperMachine.config.json` inside the module so the scaffold could read it as a template — but the script's config-file lookup chain *also* looked at `$PSScriptRoot`, which meant the bundled file silently shadowed user-scope config locations. PSGallery installs were running with the maintainer's bundled config and never got the scaffold prompt. Fixed: `$PSScriptRoot` is no longer in the lookup chain. The bundled file is now strictly the template source for the scaffold; the active-config lookup considers user locations only (`-ConfigFile`, `$PWD`, `%AppData%\…`, `~\.config\…`).
- **Blocking-process warning no longer offers the misleading `[S] Suspend` option.** PowerShell's default `ShouldContinue` prompt presents `[Y] Yes [N] No [S] Suspend [?] Help`. Several users picked `S` thinking it meant "skip" — it actually drops the user into a *nested* PowerShell sub-shell while the original script (and its single-instance lock) stays alive. Subsequent runs then hit `Another instance of Initialize-DeveloperMachine is already running.` The prompt is now a plain Y/N; the trapdoor option is gone.
- **`Ctrl+C` hook for defensive lock-file cleanup.** The existing `try/finally` already releases the lock on Ctrl+C-during-cmdlet (PipelineStoppedException unwinds finally cleanly), but Ctrl+C *while sitting at an interactive prompt* didn't always reach the finally on every host. New `Console.CancelKeyPress` handler disposes the lock stream and removes the lock file directly, idempotent with the finally so neither path leaves stale state behind.
See the [README](https://github.com/gonace/Initialize-DeveloperMachine#readme) for full configuration details.
FileList
- Initialize-DeveloperMachine.nuspec
- Initialize-DeveloperMachine.config.json
- Initialize-DeveloperMachine.ps1
- Initialize-DeveloperMachine.psd1
- Initialize-DeveloperMachine.psm1
- LICENSE
- README.md
- lib\CacheLocation.ps1
- lib\ConfigScaffold.ps1
- lib\Docker.ps1
- lib\EnvBroadcast.ps1
- lib\Junction.ps1
- lib\Lock.ps1
- lib\Node.ps1
- lib\PathsConfig.ps1
- lib\Preflight.ps1
- lib\Spinner.ps1
- lib\Status.ps1
- lib\TaskMenu.ps1
- lib\Winget.ps1
- lib\Wsl.ps1
- tasks\10-NuGet.ps1
- tasks\20-NPM.ps1
- tasks\30-VCPKG.ps1
- tasks\40-Dotnet.ps1
- tasks\50-Claude.ps1
- tasks\60-Wsl.ps1
- tasks\70-WslDistros.ps1
- tasks\90-DockerDesktop.ps1
Version History
| Version | Downloads | Last updated |
|---|---|---|
| 0.1.2 (current version) | 4 | 5/7/2026 |
| 0.1.1 | 3 | 5/7/2026 |
| 0.1.0 | 5 | 5/7/2026 |