By default, child_process.fork() will spawn new Node.js instances using the process.execPath of the parent process. The execPath property in the options object allows for an alternative execution path to be used.
This can be accomplished easily by plumbing these two params through the passed opts. I'd like to submit a PR but first I'd like some input from the maintainers on the testing approach:
I could include node binaries for various platforms and cpu architectures in the test folder, sniff os and choose the correct one to point at with execPath, then verify process.execPath from the child process. This seems like overkill.
I could symlink system node into the test folder with fs.symlink(process.execPath, newPath), point execPath to symlinked node, then verify process.execPath from the child process. The symlink would then be deleted on test completion.
I could mock child_process with mock-require, mockery, proxyquire, rewire, etc.
MrCheater
commented
6 years ago
This would be useful for scenarios where the child process needs to use a different runtime than the parent.
From the docs for
child_process.fork:This can be accomplished easily by plumbing these two params through the passed
opts. I'd like to submit a PR but first I'd like some input from the maintainers on the testing approach:osand choose the correct one to point at withexecPath, then verifyprocess.execPathfrom the child process. This seems like overkill.fs.symlink(process.execPath, newPath), pointexecPathto symlinked node, then verifyprocess.execPathfrom the child process. The symlink would then be deleted on test completion.child_processwith mock-require, mockery, proxyquire, rewire, etc.