Open in StackBlitz

npm i https://pkg.pr.new/rescript-lang/rescript@7844

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-arm64@7844

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-x64@7844

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-arm64@7844

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-x64@7844

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/runtime@7844

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/win32-x64@7844

commit:ba50294

Worked on Windows as well.

👍 from me, great stuff! But would be good if@cknitt had a look.

Thanks! I wonder if this logic shouldn't be extracted to some helper function and used in other places, too, like bsc.js or in the rescript legacy code.

Actually we already havelib_dev/process.js with similar utility functions, so it could go there.

Hmm, I'm not sure really, I’d prefer keeping this in the CLI runtime rather than lib_dev/process.js (which is dev/test-only and has different behavior).

bsc.js runs a single-shot compiler invocation without a watch loop. There’s no long-lived child to gracefully tear down on Ctrl+C, so execFileSync is appropriate and simpler. The problem we fixed only shows up in rescript.js because rewatch runs indefinitely and needs orderly signal forwarding/cleanup.

The user problem is with rescript.js, fixing it there seems fine to me.