"Channel closed" error in child on graceful shutdown after SIGTERM

[everhardt]

Issue description

When ts-node-dev sends a SIGTERM signal to the child process (for example when it detects a change in one of the watched files), it disconnects the IPC first. If the child then has a graceful shutdown function that includes logic require'ing a file it did not require before, the following error will be thrown in the child process:

Error: Channel closed
    at new NodeError (node:internal/errors:372:5)
    at process.target.send (node:internal/child_process:741:16)
    at Object.exports.send ([...]/node_modules/ts-node-dev/lib/ipc.js:17:14)
    at [...]/node_modules/ts-node-dev/lib/wrap.js:88:9
    at Object.nodeDevHook [as .js] ([...]/node_modules/ts-node-dev/lib/hook.js:61:17)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at [some code calling require(..)]

That's because the hook that calls the IPC is still in place. I think the fix is to also remove the hook before calling killChild.

Context

OS version (is it docker or host?), ts-node-dev version
macOS 12.4 (21F79), ts-node-dev 2.0.0

Did you try to run with ts-node?
Yes, no problem

Did you try to run with --files option enabled?
No

Did you try to run with --debug option enabled?
Yes, I see these logs before my graceful shutdown function kicks in:

[DEBUG] 16:09:06 Removing all watchers from files
[DEBUG] 16:09:06 Child is still running, restart upon exit
[DEBUG] 16:09:06 Disconnecting from child
[DEBUG] 16:09:06 Sending SIGTERM kill to child pid 48135

Do you have a repro example (git repo) with simple steps to reproduce your problem?
If really needed I could create one, but I think the issue and fix are obvious

[everhardt]

My fix might not be perfect, as I now occasionally see
[ERROR] 17:32:55 Error: Connection lost: The server closed the connection.

[everhardt]

Tried another approach now, where I check whether the IPC is connected before sending anything. That seems to work :).