'node' is not recognized as an internal or external command, operable program or batch file. #9424

shimizu-izumi · 2024-11-12T18:08:49Z

Verify canary release

I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

https://github.com/vercel/turborepo/tree/main/examples/basic

What package manager are you using / does the bug impact?

pnpm

What operating system are you using?

Windows

Which canary version will you have in your reproduction?

2.2.3

Describe the Bug

Executing any turbo task in PowerShell results in the following error with PNPM 9.12.3:

'node' is not recognized as an internal or external command, operable program or batch file.

node is registed on the PATH and is available in PowerShell

Expected Behavior

turbo commands successfully execute

To Reproduce

use pnpm 9.12.3 to create a new turborepo using pnpm dlx create-turbo@latest --example basic
cd into the newly created turborepo
execute pnpm run dev

Additional context

Exact PowerShell version: 7.4.6

Full execution log with debug verbosity

my-turborepo@ dev F:\my-turborepo
turbo dev "--filter" "web" "--verbosity" "2"

2024-11-12T19:05:20.965+0100 [DEBUG] turborepo_lib::shim: Global turbo version: 2.2.3
2024-11-12T19:05:20.967+0100 [DEBUG] turborepo_lib::shim: Repository Root: F:\my-turborepo
2024-11-12T19:05:20.967+0100 [DEBUG] turborepo_lib::shim::local_turbo_state: No local turbo binary found at: F:\my-turborepo\node_modules\turbo-windows-64\bin\turbo.exe
2024-11-12T19:05:20.967+0100 [DEBUG] turborepo_lib::shim::local_turbo_state: No local turbo binary found at: F:\my-turborepo\node_modules\turbo\node_modules\turbo-windows-64\bin\turbo.exe
2024-11-12T19:05:20.967+0100 [DEBUG] turborepo_lib::shim::local_turbo_state: Local turbo path: F:\my-turborepo\node_modules.pnpm\turbo-windows-64@2.2.3\node_modules\turbo-windows-64\bin\turbo.exe
2024-11-12T19:05:20.967+0100 [DEBUG] turborepo_lib::shim::local_turbo_state: Local turbo version: 2.2.3
2024-11-12T19:05:20.969+0100 [DEBUG] turborepo_lib::shim: Currently running turbo is local turbo.
turbo 2.2.3

2024-11-12T19:05:20.975+0100 [DEBUG] turborepo_lib::process: spawning children with pty: true
2024-11-12T19:05:20.976+0100 [DEBUG] turborepo_lib::daemon::connector: looking for pid in lockfile: AbsoluteSystemPathBuf("C:\Users\Izumi\AppData\Local\Temp\turbod\94a4c8776e0eb18f\turbod.pid")
WARNING stale pid file at "C:\Users\Izumi\AppData\Local\Temp\turbod\94a4c8776e0eb18f\turbod.pid"
2024-11-12T19:05:20.976+0100 [DEBUG] turborepo_lib::daemon::connector: no pid found, starting daemon
2024-11-12T19:05:20.982+0100 [DEBUG] log: No cached session for DnsName(DnsName(DnsName("telemetry.vercel.com")))
2024-11-12T19:05:20.982+0100 [DEBUG] log: Not resuming any session
2024-11-12T19:05:21.001+0100 [DEBUG] log: Using ciphersuite TLS13_AES_128_GCM_SHA256
2024-11-12T19:05:21.001+0100 [DEBUG] log: Not resuming
2024-11-12T19:05:21.002+0100 [DEBUG] log: TLS1.3 encrypted extensions: [Protocols([6832])]
2024-11-12T19:05:21.002+0100 [DEBUG] log: ALPN protocol is Some(b"h2")
2024-11-12T19:05:21.002+0100 [DEBUG] log: Ticket saved
2024-11-12T19:05:21.008+0100 [DEBUG] turborepo_lib::daemon::connector: got daemon with pid: 26608
2024-11-12T19:05:21.008+0100 [DEBUG] turborepo_lib::daemon::connector: connecting to socket: C:\Users\Izumi\AppData\Local\Temp\turbod\94a4c8776e0eb18f\turbod.sock
2024-11-12T19:05:21.009+0100 [DEBUG] turborepo_lib::daemon::connector: socket error: transport error
2024-11-12T19:05:21.067+0100 [DEBUG] turborepo_lib::daemon::connector: looking for pid in lockfile: AbsoluteSystemPathBuf("C:\Users\Izumi\AppData\Local\Temp\turbod\94a4c8776e0eb18f\turbod.pid")
2024-11-12T19:05:21.068+0100 [DEBUG] turborepo_lib::daemon::connector: found pid: 26608
2024-11-12T19:05:21.068+0100 [DEBUG] turborepo_lib::daemon::connector: got daemon with pid: 26608
2024-11-12T19:05:21.068+0100 [DEBUG] turborepo_lib::daemon::connector: connecting to socket: C:\Users\Izumi\AppData\Local\Temp\turbod\94a4c8776e0eb18f\turbod.sock
2024-11-12T19:05:21.068+0100 [DEBUG] tower::buffer::worker: "processing request"
2024-11-12T19:05:21.069+0100 [DEBUG] turborepo_lib::daemon::connector: connected in 93689µs
2024-11-12T19:05:21.070+0100 [DEBUG] turborepo_lib::run::builder: running in daemon mode
2024-11-12T19:05:21.070+0100 [DEBUG] turborepo_repository::discovery: discovering packages using caching strategy
2024-11-12T19:05:21.070+0100 [DEBUG] turborepo_repository::discovery: discovering packages using primary strategy
2024-11-12T19:05:21.070+0100 [DEBUG] turborepo_repository::discovery: discovering packages using fallback strategy
2024-11-12T19:05:21.070+0100 [DEBUG] turborepo_repository::discovery: attempting primary strategy
2024-11-12T19:05:21.070+0100 [DEBUG] turborepo_lib::run::package_discovery: discovering packages using daemon
2024-11-12T19:05:21.070+0100 [DEBUG] tower::buffer::worker: "processing request"
2024-11-12T19:05:21.071+0100 [DEBUG] turborepo_repository::discovery: discovering packages using caching strategy
2024-11-12T19:05:21.071+0100 [DEBUG] turborepo_repository::discovery: discovering packages using caching strategy
2024-11-12T19:05:21.080+0100 [DEBUG] turborepo_repository::discovery: discovering packages using caching strategy
2024-11-12T19:05:21.080+0100 [DEBUG] turborepo_lib::run::task_access: TASK ACCESS TRACE: unable to restore config from cache
• Packages in scope: web
• Running dev in 1 packages
• Remote caching disabled
┌ web#dev > cache bypass, force executing 589a1dd12f69a0fe
│
│ > [email protected] dev F:\my-turborepo\apps\web
│ > next dev --turbo
│
│ 'node' is not recognized as an internal or external command,
│ operable program or batch file.
│ ELIFECYCLE Command failed with exit code 1.
│
│ command finished with error: command (F:\my-turborepo\apps\web) C:\Program Files\nodejs\pnpm.CMD ru
│ n dev exited (1)
└────>
web#dev: command (F:\my-turborepo\apps\web) C:\Program Files\nodejs\pnpm.CMD run dev exited (1)

Tasks: 0 successful, 1 total
Cached: 0 cached, 1 total
Time: 471ms
Failed: web#dev

2024-11-12T19:05:21.448+0100 [DEBUG] turborepo_lib::process: waiting for 0 processes to exit
ERROR run failed: command exited (1)
2024-11-12T19:05:21.692+0100 [DEBUG] turborepo_telemetry: telemetry handle closed
2024-11-12T19:05:21.692+0100 [DEBUG] log: Sending warning alert CloseNotify
ELIFECYCLE Command failed with exit code 1.

The text was updated successfully, but these errors were encountered:

chris-olszewski · 2024-11-12T18:27:39Z

I believe this is related to environment variables. Can you quick try --env-mode=loose and see if that solves the issue?

Can you also run Get-ChildItem env:Path along with Get-Command node and provide those just to double check that that aren't any intermediate env vars needed to find node on your system?

shimizu-izumi · 2024-11-12T18:38:58Z

--env-mode=loose:
Worked

Get-ChildItem env:Path:

PSPath : Microsoft.PowerShell.Core\Environment::Path
PSDrive : Env
PSProvider : Microsoft.PowerShell.Core\Environment
PSIsContainer : False
Name : path
Key : path
Value : C:\Program Files\PowerShell\7;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\Program Files\nodejs;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Microsoft VS Code\bin;C:\Program Files\starship\bin;C:\ProgramData\miniconda3\condabin;C:\Program Files\Git\cmd;C:\Program Files\dotnet;C:\Program Files\Docker\Docker\resources\bin;C:\Program Files\PowerShell\7;C:\Users\Izumi\AppData\Local\Microsoft\WindowsApps;C:\Program Files\JetBrains\WebStorm 2024.2.4\bin;C:\Users\Izumi.dotnet\tools;C:\Users\Izumi\AppData\Local\spicetify;C:\Users\Izumi\AppData\Roaming\npm

Get-Command node:
CommandType Name Version Source

Application node.exe 22.11.0.0 C:\Program Files\nodejs\node.exe

Is there something in Windows that I can change to get the "original" behaviour back? I encountered this issue after freshly installing Windows, a few days ago before I reinstalled it worked without --env-mode=loose

shimizu-izumi · 2024-11-12T18:50:52Z

so uhm, I did the unthinkable and renamed the system path variable from path to PATH and it works like expected now

chris-olszewski · 2024-11-12T20:25:38Z

Ah, I've only seen Path or PATH on Windows depending on if you use Powershell or Command Prompt. I'll get path added as well.

shimizu-izumi · 2024-11-12T20:28:01Z

Could be something new with Windows 11 24H2, build 26100.2161 to be more specific

chris-olszewski · 2024-11-13T14:30:06Z

PR #9429 should make us more resilient on Windows by treating env vars as they're meant to be treated (case in-sensitive)

### Description In #9424 a user had `path` as their Windows env var instead of `Path` or `PATH`. On Windows environment variables are case insensitive e.g. `process.env.PATH` and `process.env.Path` would both return the same. While fetching them might be the same [`std::env::vars`](https://doc.rust-lang.org/std/env/fn.vars.html) returns the environment variable names cased as they were declared even though [`std::env::var`](https://doc.rust-lang.org/std/env/fn.var.html) is case insensitive on Windows. Take for example the following code: ``` for (key, value) in std::env::vars() { println!("{key}: {value}"); let lowercase = key.to_ascii_lowercase(); println!("{lowercase}: {:?}", std::env::var(&lowercase)); } ``` On Windows it outputs: ``` ... PUBLIC: C:\Users\Public public: Ok("C:\\Users\\Public") SESSIONNAME: Console sessionname: Ok("Console") SystemDrive: C: systemdrive: Ok("C:") SystemRoot: C:\WINDOWS systemroot: Ok("C:\\WINDOWS") TEMP: C:\Users\Chris\AppData\Local\Temp temp: Ok("C:\\Users\\Chris\\AppData\\Local\\Temp") TMP: C:\Users\Chris\AppData\Local\Temp tmp: Ok("C:\\Users\\Chris\\AppData\\Local\\Temp") ``` On macOs it outputs: ``` ... TMPDIR: /var/folders/3m/rxkycvgs5jgfvs0k9xcgp6km0000gn/T/ tmpdir: Err(NotPresent) TMUX: /private/tmp/tmux-501/default,3104,0 tmux: Err(NotPresent) TMUX_PANE: %4 tmux_pane: Err(NotPresent) USER: olszewski user: Err(NotPresent) USER_ZDOTDIR: /Users/olszewski user_zdotdir: Err(NotPresent) ``` Previously we had special casing for well known Windows env vars that were set differently between Command Prompt and Powershell, but would break if a user overwrote `Path` or `PATH` to `path`. This was brittle and a correct solution would require that we include all casing variations of all environment variables and users would also need to know how env vars were declared on their Windows system. This fix is to make our env var wildcard handling case in ### Testing Instructions Added unit test to make sure we

shimizu-izumi added kind: bug Something isn't working needs: triage New issues get this label. Remove it after triage labels Nov 12, 2024

chris-olszewski removed the needs: triage New issues get this label. Remove it after triage label Nov 12, 2024

chris-olszewski added the needs: author input label Nov 12, 2024

shimizu-izumi closed this as completed Nov 12, 2024

chris-olszewski mentioned this issue Nov 13, 2024

fix(windows): fix env var glob casing #9429

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

'node' is not recognized as an internal or external command, operable program or batch file. #9424

'node' is not recognized as an internal or external command, operable program or batch file. #9424

shimizu-izumi commented Nov 12, 2024 •

edited

Loading

chris-olszewski commented Nov 12, 2024

shimizu-izumi commented Nov 12, 2024

shimizu-izumi commented Nov 12, 2024

chris-olszewski commented Nov 12, 2024

shimizu-izumi commented Nov 12, 2024

chris-olszewski commented Nov 13, 2024

'node' is not recognized as an internal or external command, operable program or batch file. #9424

'node' is not recognized as an internal or external command, operable program or batch file. #9424

Comments

shimizu-izumi commented Nov 12, 2024 • edited Loading

Verify canary release

Link to code that reproduces this issue

What package manager are you using / does the bug impact?

What operating system are you using?

Which canary version will you have in your reproduction?

Describe the Bug

Expected Behavior

To Reproduce

Additional context

chris-olszewski commented Nov 12, 2024

shimizu-izumi commented Nov 12, 2024

shimizu-izumi commented Nov 12, 2024

chris-olszewski commented Nov 12, 2024

shimizu-izumi commented Nov 12, 2024

chris-olszewski commented Nov 13, 2024

shimizu-izumi commented Nov 12, 2024 •

edited

Loading