Enable passthrough IPC in watch mode

[znewsham]

Fixes #50880

When spawning a node process in watch mode, from another node process, there is currently no way to get IPC between the parent and the child. This PR enables this bi-directional flow:

• parent -> watcher -> child
• child -> watcher -> parent

This setup is useful in situations where you have a process responsible for building and running a client/server application which needs to be made aware (via IPC) that it's client bundle has changed and needs to be re-served, without restarting the server.

[debadree25]

I think this should be directed towards the main branch

[znewsham]

I think this should be directed towards the main branch

I confess, I'm not totally clear on the branching structure. I'd like this to be available in node 18, are you suggesting I point at v18.x or somewhere else?

[debadree25]

So the general process is we land changes onto the main branch of this repo and then changes are backported to the release lines you can read about it here https://github.com/nodejs/node/blob/main/doc/contributing/backporting-to-release-lines.md
so for your case your branch should towards the main branch and after this change is approved and landed it shall be backported by the releasers to the 18.x branch and be available in 18.x

[MoLow]

please also resolve conflicts

[znewsham]

This will almost certainly require a backport PR

noting the original commit for my reference later: ad2131716bdd45d4279a9780f50e11e1aa4302ef

[debadree25]

Could you fix the first commit message according to the guidelines https://github.com/nodejs/node/blob/main/doc/contributing/pull-requests.md#commit-message-guidelines , and these few linting issues that it complains about.

[znewsham]

Both of those are fixed - for some reason I can't get eslint to play nice with vscode - but the linting is now resolved.

[MoLow]

Changes LGTM, but I think the test can be simplified more

[MoLow]

LGTM

[benjamingr]

Nice

[znewsham]

Just want to check on the next steps here - the contribution guide suggests I should kick off the CI build and add an "Author Ready" label - I don't believe I have permissions to do either

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/56076/

[znewsham]

What's the best way to debug failures on specific architectures? E.g.,
node-test-commit-arm-fanned
node-test-commit-linuxone-rhel8-s390x

I could probably get myself access to an arm machine if necessary

[znewsham]

@MoLow I've rebased to remove the rewatch changes, which are now extracted here: #52879

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/59042/

[znewsham]

@MoLow I apologise, the failing test was caused by a previously fixed test that the rebase must have removed (an extraneous ' in the expected test result). Could you please re-trigger the CI run

[github-actions]

Failed to start CI

   ⚠  Something was pushed to the Pull Request branch since the last approving review.
   ✘  Refusing to run CI on potentially unsafe PR

https://github.com/nodejs/node/actions/runs/9014337858

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/59046/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/59047/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/59049/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/59056/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/59059/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/59061/

[nodejs-github-bot]

Landed in 70995bd

[znewsham]

@MoLow thanks for your help in getting this across the line - I've read through the contribution guide (and the backporting guide), but it still isn't clear to me which release this will appear in (or when) - will it be a minor version increase in v22, or does it have to wait until v23? Is backporting to v20 (or even v18, it's not clear what "maintenance" means) an option?

[MoLow]

It should get to all active releases (20, 21, 22)