fix(desktop): skip slow powershell profile load if node is available

[mohamedmastouri-hue]

Fixes #4403 by skipping the slow PowerShell profile load if node.exe is already found in the no-profile path.

---

Note

Medium Risk
Changes Windows PATH and FNM-related env hydration at startup; early exit may omit profile-only variables when PowerShell is skipped, though fnm users still get full probes.

Overview
Windows desktop startup can now avoid spawning PowerShell entirely when node.exe is discoverable from known CLI directories and the current PATH, and no fnm wrapper is present.

installWindowsEnvironment adds a filesystem pre-check (with quoted-path trimming), sets PATH from the static merge, and returns early. If fnm is detected alongside Node, the existing two concurrent PowerShell probes still run. When probes run, PATH merging is reordered so profile PATH is layered on top of known dirs, no-profile PATH, and the inherited env.

Tests gain optional mock FileSystem wiring and three cases covering skip vs concurrent probes vs Node only in knownWindowsCliDirs.

^{Reviewed by Cursor Bugbot for commit 5306f4b. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Skip PowerShell profile load on Windows when node is statically discoverable

• On Windows, installWindowsEnvironment now checks for node.exe in known CLI directories and the current PATH before spawning any PowerShell processes.
• If node.exe is found and no fnm wrapper is present, PATH is set from the static merge and the function returns early, avoiding slow PowerShell profile loads.
• If fnm is detected alongside node.exe, two PowerShell probes (one with -NoProfile, one with profile) still run concurrently as before.
• PATH merging order is revised: known CLI dirs + no-profile PATH + current env PATH, then combined with the full-profile PATH.
• Behavioral Change: Windows shell startup no longer spawns PowerShell at all when node is found in static locations without fnm.

^{Macroscope summarized 5306f4b.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 33f4573c-1dd4-40af-8b52-33b952804b78

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding on the Windows shell-environment fast path: the {} placeholder for a skipped profile probe drops the EnvironmentPatch type and silently disables FNM hydration, and this backend behavior change has no focused test.

Convention referenced: If backend behavior changes, require focused tests (change discipline). The existing Windows test still exercises only the profile-loading path, because it runs against the real NodeServices filesystem where ...\node.exe never exists; the new skip branch is untested.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR changes Windows startup behavior by conditionally skipping PowerShell profile probes based on file system checks. While the performance intent is clear, the new heuristics gate significant behavior and could have edge cases (e.g., other node version managers). The author is also new to this file.

^{You can customize Macroscope's approvability policy. Learn more.}

[macroscopeapp]

Two issues in the new Windows startup tests: the added cases are currently unreachable (never registered with the test runner), and once registered they depend on real filesystem lookups with Windows path separators, so they cannot pass on non-Windows CI. Since this PR changes Windows startup behavior, the focused tests need to actually run and be platform-independent.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One retained finding after the restructure into Effect.all: the skipped-profile branch still yields an untyped {}, which widens the tuple element and breaks the later profile.PATH / profile.FNM_DIR reads. Details inline.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Effect service conventions review: one change-discipline finding on the removed concurrency rationale. The service definition, layer, dependency acquisition (yield* FileSystem.FileSystem), and error modeling all look consistent with the conventions, and the new tests are now registered at describe level and platform-independent.

^{Posted via Macroscope — Effect Service Conventions}

Dismissing prior approval to re-evaluate 989bfa7

[macroscopeapp]

One finding on the new Windows fast-path tests: the knownWindowsCliDirs case does not exercise the path it claims to. Production code changes look consistent with the service conventions (dependency acquired via yield* FileSystem.FileSystem, namespace imports, preserved concurrency rationale).

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding: the fast-path pre-check is fine as an Effect service change (dependency acquired via yield* FileSystem.FileSystem, requirement surfaced in the Effect.fn.Return type, make/layer unchanged), but the Windows path-separator rewrite in knownWindowsCliDirs changes production behavior beyond the perf fix.

^{Posted via Macroscope — Effect Service Conventions}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 030ff8a. Configure here.}

[macroscopeapp]

One convention issue: the new FileSystem usages in the test file have no corresponding namespace import.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One import-convention violation found in the changed test file. See the inline comment.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One convention issue found: the test provides a FileSystem tag from a different package than the service under test requires.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding in the test harness: the conditional Effect.provideService leaves FileSystem.FileSystem in the helper's declared requirements, so every it.effect call site in this file no longer typechecks.

^{Posted via Macroscope — Effect Service Conventions}