fix: resolve Windows worker PATH names case-insensitively

[Dcastroro]

Fixes #108.

Windows worker environments are case-sensitive, so a worker with a Path key and no PATH currently cannot resolve commands from that directory. Node documents this distinction in process.env.

When the default environment path is needed, keep an explicitly present PATH (including an empty string). Only on Windows, if it is absent, look for another casing of that key. Read the current environment on each call, preserving the documented no-cache behavior. Explicit path options still take precedence, and POSIX continues using only uppercase PATH.

Add nine regression cases covering Path/path/pAtH, uppercase and empty PATH, explicit path options, POSIX behavior, missing paths, environment changes between calls, and a real Windows worker. That worker receives only a synthetic Path and PATHEXT; it does not inherit the parent environment or execute the fixture command.

Validation on Windows / Node 24.20.0:

• Before the fix, five of the nine new cases fail, including the real worker reproduction.
• npm test passes the complete suite, 100% statement/branch/function/line coverage, ESLint and template-oss-check.
• git diff --check passes.
• Only lib/index.js and the new test/path-env.js change. No dependencies, generated tooling or workflow files are changed, and no credentials are included.

Checked the complete open-PR list and issue timeline before implementation/publication; no overlapping open PR was present.

Prepared and tested with Codex assistance. Native Linux/macOS runs were not performed locally; POSIX lookup behavior is covered by the isolated platform tests. The upstream CI workflow restricts its jobs to the npm organization, so a fork run would not provide equivalent validation.

[Copilot]

🔵 Needs a closer look

It changes default PATH resolution behavior in a foundational, widely-depended-upon utility, and the authoritative Windows worker reproduction test is skipped outside native Windows CI, so a maintainer should give final sign-off.

0 open findings

What changed in this PR

This PR fixes issue #108, where which fails to resolve executables on Windows worker threads because the environment is case-sensitive there and the PATH variable is only present under a different casing (e.g. Path). A new getPathEnv() helper is used as the default for the path option: on POSIX (and whenever an exact PATH key exists, including an empty string) it returns process.env.PATH unchanged, and only on Windows when PATH is truly absent does it scan process.env for a case-insensitive path key. Reading the environment on each call preserves the library's documented no-cache behavior, and explicit path options still take precedence.

Changes:

• Add getPathEnv() in lib/index.js and use it as the default for the path option, with a Windows-only case-insensitive PATH fallback.
• Preserve existing semantics: POSIX only uses PATH, an explicitly present (even empty) PATH is not overridden, and explicit path options win.
• Add test/path-env.js with nine regression cases, including a native-Windows-only worker-thread reproduction.

File	Description
lib/​index.js	Introduces getPathEnv() and wires it into getPathInfo's default path resolution to handle case-insensitive PATH on Windows workers.
test/​path-env.js	New test suite covering Path/path/pAtH fallback, empty/uppercase PATH, explicit path options, POSIX behavior, not-found cases, per-call env reads, and a real Windows worker.

🧠 Review effort: Balanced

---

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