"unstable_dev" doesn't kill app server on exit (Windows)

[trevor-hackett]

What version of Remix are you using?

1.16.0

Are all your remix dependencies & dev-dependencies using the same version?

• Yes

Steps to Reproduce

On a Windows machine, create a new Remix app with unstable_dev enabled. (ex: npx create-remix@latest --template https://github.com/remix-run/remix/tree/templates_v2_dev/templates/remix my-app)

Run the app. (npm run dev)

Kill the process (ex: CTRL-C)

Expected Behavior

Dev server and app server should exit

Actual Behavior

Dev server exits but app server process continues to run and has to be killed separately.

[trevor-hackett]

Looks like it is just the way execa and NodeJS works by default on Windows. The spawned process doesn't exit when the process is killed. To get this to work, windowsHide must be disabled.

See:

• Windows: execa leaving processes around when running npm scripts in a sh shell sindresorhus/execa#433
• https://github.com/sindresorhus/execa#windowshide

Despite it saying that a new console would open, I haven't seen another console open with this disabled.

[pcattori]

possibly fixed by #6289 which is available in nightly

[trevor-hackett]

This isn't about the development loop (restart app server on changes).

This is when you kill the development process altogether. The child process (app server) is not killed with the dev server. The app server process is left running and you can't start up a new process (npm run dev) until you manually kill the node process

[trevor-hackett]

Just to confirm. I installed the latest nightly and it is still happening.

For more context this is what I'm doing:

> dev
> remix dev

💿 Building...
💿 Built in 537ms
Waiting for app server (07d97bd0)
> remix-serve build\index.js
Remix dev server ready
Remix App Server started at http://localhost:3000 (http://192.168.169.228:3000)
App server took 278ms
Terminate batch job (Y/N)? y
PS D:\dev\my-app22> npm run dev

> dev
> remix dev

💿 Building...
💿 Built in 528ms
Waiting for app server (07d97bd0)
> remix-serve build\index.js
Remix dev server ready
Error: listen EADDRINUSE: address already in use :::3000
    at Server.setupListenHandle [as _listen2] (node:net:1740:16)
    at listenInCluster (node:net:1788:12)
    at Server.listen (node:net:1876:7)
    at Function.listen (D:\dev\my-app22\node_modules\.pnpm\[email protected]\node_modules\express\lib\application.js:635:24)
    at Object.<anonymous> (D:\dev\my-app22\node_modules\.pnpm\@[email protected]\node_modules\@remix-run\serve\dist\cli.js:48:84)
    at Module._compile (node:internal/modules/cjs/loader:1254:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
    at Module.load (node:internal/modules/cjs/loader:1117:32)
    at Function.Module._load (node:internal/modules/cjs/loader:958:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)

Adding windowsHide: false to this fixes the issue:

remix/packages/remix-dev/devServer_unstable/index.ts

Lines 69 to 77 in d8bcdc1

	let newAppServer = execa.command(command, {
	stdio: "pipe",
	env: {
	NODE_ENV: "development",
	PATH:
	bin + (process.platform === "win32" ? ";" : ":") + process.env.PATH,
	REMIX_DEV_HTTP_ORIGIN: stringifyOrigin(httpOrigin),
	},
	});

Example:

 let newAppServer = execa.command(command, { 
   stdio: "pipe", 
   env: { 
     NODE_ENV: "development", 
     PATH: 
       bin + (process.platform === "win32" ? ";" : ":") + process.env.PATH, 
     REMIX_DEV_HTTP_ORIGIN: stringifyOrigin(httpOrigin), 
   }, 
   windowsHide: false
 }); 

PS D:\dev\my-app22> npm run dev

> dev
> remix dev

💿 Building...
💿 Built in 528ms
Waiting for app server (07d97bd0)
> remix-serve build\index.js
Remix dev server ready
Remix App Server started at http://localhost:3000 (http://192.168.169.228:3000)
App server took 272ms
Terminate batch job (Y/N)? 
^C
PS D:\dev\my-app22> npm run dev

> dev
> remix dev

💿 Building...
💿 Built in 531ms
Waiting for app server (07d97bd0)
> remix-serve build\index.js
Remix dev server ready
Remix App Server started at http://localhost:3000 (http://192.168.169.228:3000)
App server took 268ms

[pcattori]

Thanks for the great detective work @trevor-hackett ! Adding this to the dev server TODOs

[roniaxe]

Can confirm to have the same issue. Starting the server once is OK, killing it and starting again getting me that error:

Remix dev server ready
Error: listen EADDRINUSE: address already in use :::3000
    at Server.setupListenHandle [as _listen2] (node:net:1485:16)
    at listenInCluster (node:net:1533:12)
    at Server.listen (node:net:1621:7)
    at Function.listen (D:\wellspring-montessori-app\wellspring-frontend-remix\node_modules\express\lib\application.js:635:24)
    at Object.<anonymous> (D:\wellspring-montessori-app\wellspring-frontend-remix\node_modules\@remix-run\serve\dist\cli.js:48:84)
    at Module._compile (node:internal/modules/cjs/loader:1159:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1213:10)
    at Module.load (node:internal/modules/cjs/loader:1037:32)
    at Function.Module._load (node:internal/modules/cjs/loader:878:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)

I then have to kill the port manually with taskkill /PID PID /F in order to start again on port 3000

[pcattori]

@trevor-hackett merged #6322, so you'll be able to try this fix out on nightly tomorrow.

I'm working on getting Parallels setup for local Windows dev on my mac, but haven't done so yet. So in the meantime, any feedback from you or others using Windows is invaluable!

[github-actions]

🤖 Hello there,

We just published version v0.0.0-nightly-360e77e-20230516 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[github-actions]

🤖 Hello there,

We just published version 1.16.1-pre.0 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[github-actions]

🤖 Hello there,

We just published version 1.16.1 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!