Resolve node's real winget package id instead of assuming LTS (#693)

[ptr727]

Summary

Fixes #693.

winget list --id OpenJS.NodeJS.LTS --exact echoes back the queried id for a package that only shares a publisher and name with what's actually installed. On a host running OpenJS.NodeJS (the Current channel), that made every report and action believe OpenJS.NodeJS.LTS was installed, and -Upgrade/-Reinstall would have targeted that wrong id.

Node also ships under many more ids than Current/LTS — one per pinned major back to 4 (OpenJS.NodeJS.4 … .23) — any of which is fine on a host as long as its version clears the LTS floor.

Fix

• Added a Family field to the tools registry in install-tools.ps1 (empty for every tool but node, which gets 'OpenJS.NodeJS').
• Added Resolve-ToolPackage, which cross-references the already-correctly-read installed version against a winget search --query <family> catalog listing. A version that uniquely matches one of the sibling ids identifies which one is truly installed, without ever trusting winget's id-scoped list --id --exact correlation.
• That resolved id ($state.Package) now flows through status, notes, the report's SOURCE column, and every install/upgrade/remove action instead of the hardcoded default.
• Other 7 managed tools are untouched (Family = '' short-circuits before any extra winget call).

Verification (done on a live host)

Host had OpenJS.NodeJS (Current, 26.7.0) installed, not OpenJS.NodeJS.LTS.

• -Report node → now shows SOURCE=OpenJS.NodeJS (was misleadingly OpenJS.NodeJS.LTS), status still correctly current (26.7.0 ≥ LTS floor 24.19.0).
• -Upgrade node -DryRun → correctly no-ops (already current).
• -Reinstall node -DryRun → now issues winget uninstall --id OpenJS.NodeJS / winget install --id OpenJS.NodeJS, i.e. it reinstalls the package that's actually there instead of silently swapping to LTS.
• Full -Report across all 8 tools → other 7 unchanged, no regressions.
• Script parses clean; PSScriptAnalyzer shows only pre-existing, unrelated Write-Host warnings.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes incorrect winget package-id resolution for Node.js on Windows by resolving the actual installed Node.js winget id (Current/LTS/pinned-major) instead of assuming OpenJS.NodeJS.LTS, preventing reports and actions from targeting the wrong package.

Changes:

• Added a Family field to the tool registry (used only for node) to represent the shared id prefix.
• Added Read-WingetSearchTable and Resolve-ToolPackage to map an installed Node.js version back to the correct sibling winget id via a family search.
• Plumbed the resolved package id through reporting, notes, and install/upgrade/remove/reinstall actions.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

host-setup/windows/install-tools.ps1:584

• Actions now target $state.Package (resolved installed id), but Available/floor is still read from $Tool.Package (Node LTS). If the installed Node id resolves to a pinned-major package whose major is below the LTS floor (e.g., OpenJS.NodeJS.23 while LTS is 24.x), -Upgrade/-Reinstall will keep upgrading/reinstalling that pinned id even though it can never reach the required major, so the tool stays permanently outdated.

Consider separating “installed package id” from “target package id”, or overriding the action target back to $record.Package when the installed major is below the required major (and updating the reinstall prompt accordingly).

    $packages = @($state.Package)
    if ($script:WITH_OPTIONAL) { $packages += $record.Optional }

    foreach ($package in $packages) {
        $code = if ($state.Rows.Count -gt 0 -and $script:MODE -eq 'upgrade' -and $package -eq $state.Package) {
            Invoke-WingetUpgrade -Id $package

[ptr727]

Re the suppressed finding on host-setup/windows/install-tools.ps1:584:

Actions now target $state.Package (resolved installed id), but Available/floor is still read from $Tool.Package (Node LTS). If the installed Node id resolves to a pinned-major package whose major is below the LTS floor (e.g., OpenJS.NodeJS.23 while LTS is 24.x), -Upgrade/-Reinstall will keep upgrading/reinstalling that pinned id even though it can never reach the required major, so the tool stays permanently outdated.

Confirmed and fixed in fee7c3a. Added $target, the id fresh work goes to, which equals the resolved installed id except when that id is outdated and not the tool's own default (the pinned/capped case), where it falls back to the default. -Upgrade now says plainly that the installed id is a fixed release and points at -Reinstall instead of retrying a doomed winget upgrade; -Reinstall now installs $target after removing the old copy, so it actually fixes a capped install rather than restoring it unchanged. A healthy alternate channel (e.g. Current, already above the floor) is untouched, since $target only diverges when the tool is outdated under the resolved id.

Verified with synthetic state (not a real winget mutation, to avoid installing a legacy Node major on a live host):

target = OpenJS.NodeJS.LTS
GUIDANCE: node: OpenJS.NodeJS.14 at 14.21.3 is a fixed release and cannot advance under that id, -Reinstall node replaces it with OpenJS.NodeJS.LTS
CONFIRM: Remove OpenJS.NodeJS.14 at 14.21.3 and install OpenJS.NodeJS.LTS instead?
target2 (healthy Current, reinstall path) = OpenJS.NodeJS  <- stays OpenJS.NodeJS, no unwanted swap to LTS

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

host-setup/windows/install-tools.ps1:578

• The new pinned-major detection ($target differs from $state.Package) is handled for -Upgrade (you log that the id is fixed and require -Reinstall), but -Install on the same state still logs that "-Upgrade moves it". For a pinned major this is inaccurate, since -Upgrade will hit the same fixed-release guard and no-op; the guidance should be consistent and point to -Reinstall when $target -ne $state.Package in both modes.

    } elseif ($script:MODE -eq 'upgrade' -and $state.Status -eq 'outdated' -and $target -ne $state.Package) {
        log "${ToolName}: $($state.Package) at $($state.Installed) is a fixed release and cannot advance under that id, -Reinstall $ToolName replaces it with $target"
        return
    } elseif ($script:MODE -eq 'install' -and $state.Status -eq 'outdated') {
        log "${ToolName}: at $($state.Installed), the source carries $($state.Available), -Upgrade moves it"
        return

[ptr727]

Re the suppressed finding on host-setup/windows/install-tools.ps1:578:

The new pinned-major detection ($target differs from $state.Package) is handled for -Upgrade ..., but -Install on the same state still logs that "-Upgrade moves it". For a pinned major this is inaccurate, since -Upgrade will hit the same fixed-release guard and no-op; the guidance should be consistent and point to -Reinstall when $target -ne $state.Package in both modes.

Confirmed and fixed in eae196a — merged the two branches so -Install and -Upgrade share the same fixed-release check and both point at -Reinstall for a capped id. Verified with synthetic state that both modes now print the identical, accurate guidance:

[upgrade] node: OpenJS.NodeJS.14 at 14.21.3 is a fixed release and cannot advance under that id, -Reinstall node replaces it with OpenJS.NodeJS.LTS
[install] node: OpenJS.NodeJS.14 at 14.21.3 is a fixed release and cannot advance under that id, -Reinstall node replaces it with OpenJS.NodeJS.LTS

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.