Add `.fork()` method about execa

[sindresorhus]

but that would mean not capitalising on the added optimization that happens when using fork, as mentioned here.

That is, as always with Stack Overflow answers, incorrect. .fork is just .spawn with an IPC channel. You can easily do that with .spawn too, by specifying it in the stdio option.

We should definitely add .fork() here though, as it's handy. I was thinking about it initially, but wanted to explore ways of making .fork() better and never got to it.

Pull request welcome :)

[sindresorhus]

If anyone wants to take on this, see #108 for context and previous work.

[IssueHuntBot]

@IssueHunt has funded $60.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[ehmicky]

Just to add to the discussion, I don't think there is any "added optimization" with fork(). If you check the Node.js source code, fork() only performs some normalization logic then calls spawn(). The extra logic introduced by fork() is:

• use process.execPath (i.e. node) as the main binary. I.e. fork('file.js') becomes spawn('node', ['file.js']). process.execPath can be modified with the execPath option.
• use process.execArgv (i.e. node CLI arguments). I.e. if node was fired with --no-warnings, fork('file.js') becomes spawn('node', ['--no-warnings', 'file.js']). process.execArgv can be modified with the execArgv option.
• add a silent option which is the same as using stdio: 'pipe'.
• always use shell: false option.

So there are no optimizations. However this is convenient for two reasons:

• it's shorter because node does not need to passed as argument
• it re-uses the current node path (if several node binaries are installed) and CLI flags.

[sindresorhus]

@ehmicky Yes, it's mostly for convenience, but also:

The returned ChildProcess will have an additional communication channel built-in that allows messages to be passed back and forth between the parent and child.

[ehmicky]

Oh yes you're right.

This could be seen as a convenience as well since this can be achieved with spawn() by adding ipc to the stdio option, e.g. stdio: ['inherit', 'inherit', 'inherit', 'ipc'] (which is what actually fork() does under the hood).

Also to my above points, we should add that fork() defaults stdio to inherit (with the additional ipc) whereas spawn() defaults it to pipe.

[sindresorhus]

If anyone wants to take on this, see #108 for context and previous work.

@GMartigny @ehmicky I think you missed this. fork() is not really a good name, as fork is already a different thing in Unix: https://en.wikipedia.org/wiki/Fork_(system_call) The Node.js name is very unfortunate, since Node.js doesn't actually "fork" in the Unix sense.

[ehmicky]

I agree that fork() is a bad name, because it does not map to Unix forks.

I think we should either:

• try to mimic the Node.js behavior and keep the fork() name.
• allow ourselves to deviate from the Node.js behavior and use a different name like execa.node() or execa.spawnNode().

Some things where we might consider deviating:
a) silent option defaulting to true instead of false
b) not offer any silent option at all? This option is not very useful, users can just use stdio-related options.
c) do not push ipc to stdio. It's very possible many users won't use that channel, so setting it up by default is not needed, and probably not cheap. The ones that do want it can specify it in stdio. Also half of the code in the current PR is related to this. However as @sindresorhus points it out in #108, if we don't do that, there might not be a need for this extra method at all, so we might still want to do it.

What do you think?

[sindresorhus]

allow ourselves to deviate from the Node.js behavior and use a different name like execa.node() or execa.spawnNode().

I think we should yes. Not sure which I like the most of execa.node() and execa.spawnNode() though.

b) not offer any silent option at all? This option is not very useful, users can just use stdio-related options.

I agree. We don't need it. It should just default to 'pipe' like normal.

c) do not push ipc to stdio. It's very possible many users won't use that channel, so setting it up by default is not needed, and probably not cheap.

I doubt it has any real performance impact.

[ehmicky]

Alright, so the consequences would be:

• rename fork() to node() or spawnNode()
• do not add any silent option. The stdio options should default to pipe (like normal execa())

@GMartigny what do you think?

[GMartigny]

Either .node or .spawnNode imply you can only use node as sub process. Should we get rid of the execPath option as well?

We can (and certainly should) keep execArgv to customize the sub process args.

[sindresorhus]

Should we get rid of the execPath option as well?

No, it's meant to be able to specify which Node.js executable you want. I already commented about clarifying the option description in your PR.

[issuehunt-oss]

@sindresorhus has rewarded $54.00 to @GMartigny. See it on IssueHunt

• 💰 Total deposit: $60.00
• 🎉 Repository reward(0%): $0.00
• 🔧 Service fee(10%): $6.00