Skip to content

Support fnm and nvm-windows Node discovery on Windows#359

Merged
cscheid merged 1 commit into
mainfrom
feature/bd-e1ger90c-support-fnm-nvm-windows
Jul 2, 2026
Merged

Support fnm and nvm-windows Node discovery on Windows#359
cscheid merged 1 commit into
mainfrom
feature/bd-e1ger90c-support-fnm-nvm-windows

Conversation

@cderv

@cderv cderv commented Jul 2, 2026

Copy link
Copy Markdown
Member

When a GUI app like Claude Desktop launches q2 mcp, the server starts with a minimal environment and no shell-sourced PATH. fnm on Windows mutates PATH only inside an interactive shell and never persists it, so a GUI-launched host never sees an fnm-managed Node. The layer-3 well-known fallback in crates/quarto-mcp-launcher/src/node.rs only probed Program Files and Volta on Windows, so discovery failed outright — node: NOT FOUND even with an fnm default installed.

Fix

Probe the two Windows-native version managers in default_well_known:

  • fnm under dirs::config_dir()/fnm — the aliases/default junction and the node-versions tree, which has no bin/ subdir on Windows (unlike unix fnm).
  • nvm-windows under %NVM_HOME% — a flat vX.Y.Z/node.exe layout with no subdir.

Rather than parameterize the version-tree walker, highest_version_node now tries a superset of sub-paths covering all four layouts (unix nvm, unix fnm, Windows fnm, nvm-windows). A sub-path for the wrong OS is never a file and is skipped, so unix resolution is unchanged. Adding Windows callers also makes the helper live on Windows, clearing a latent dead_code warning.

nvm-windows persists its active version to PATH via the registry, so most GUI apps already inherit it; that probe is defense-in-depth. The confirmed-broken case is fnm.

Test Plan

  • highest_version_node selects the newest version across all four layouts (unit tests)
  • With PATH stripped to Windows system dirs and an fnm default set, q2 mcp --launcher-info reports the fnm Node instead of NOT FOUND
  • Unix discovery is unchanged

A GUI-launched MCP host (Claude Desktop) starts `q2 mcp` with a minimal
environment. fnm mutates PATH only inside an interactive shell and never
persists it, so its Node is invisible to such a host — and the layer-3
well-known fallback only probed Program Files and Volta on Windows, so
discovery failed outright even with an fnm default set.

Probe the two Windows-native version managers directly: fnm under
dirs::config_dir()/fnm (aliases/default junction + the node-versions
tree, which has no bin/ subdir on Windows) and nvm-windows under
NVM_HOME (flat vX.Y.Z/node.exe). Rather than parameterize the tree
walker, highest_version_node just tries a superset of sub-paths; a
sub-path for the wrong OS is never a file and is skipped, so unix
resolution is unchanged. Adding Windows callers also makes the helper
live on Windows, clearing a latent dead_code warning.

Also gate an unused-on-Windows PathBuf import in the launcher's node
integration tests behind cfg(unix); it only compiled clean because CI
is unix-only.
@posit-snyk-bot

posit-snyk-bot commented Jul 2, 2026

Copy link
Copy Markdown

Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues
Licenses 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@cscheid

cscheid commented Jul 2, 2026

Copy link
Copy Markdown
Member

Thanks!

@cscheid cscheid merged commit 8cd9003 into main Jul 2, 2026
8 checks passed
@cscheid cscheid deleted the feature/bd-e1ger90c-support-fnm-nvm-windows branch July 2, 2026 12:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants