Make error.killed more consistent

[ehmicky]

error.killed is always true or false with execa().

But with execa.sync(), it can also be undefined sometimes, e.g. on ENOENT. This PR ensures error.killed is always a boolean.

Details:

• spawn() returns a childProcess with childProcess.killed
• spawnSync() does not return this, but we can emulate most of the cases by checking the signal property.

Tests are added for this as well.

[sindresorhus]

Unrelated to this PR, but what do you think about renaming .killed to .isKilled for naming consistency?

[sindresorhus]

spawnSync() does not return this, but we can emulate most of the cases by checking the signal property.

It's weird that the synchronous version has this inconsistency. Should we open a Node.js issue about it?

[ehmicky]

It's weird that the synchronous version has this inconsistency. Should we open a Node.js issue about it?

That's because spawn() return a ChildProcess instance, while spawnSync() returns a plain object with fewer/different properties. It's not only killed. I think Node.js would say it's a design decision.

Unrelated to this PR, but what do you think about renaming .killed to .isKilled for naming consistency?

isKilled is more consistent with isCanceled. However spawned.killed already exists in core Node.js, so I would think using property names users are already expecting or familiar with is more important.

[sindresorhus]

isKilled is more consistent with isCanceled. However spawned.killed already exists in core Node.js, so I would think using property names users are already expecting or familiar with is more important.

You could argue that about .code vs exitCode though.

[ehmicky]

Yes I thought of that as well. The thing is .code is actually different from exitCode because they don't have the same type. Whereas .killed is almost identical both in type and behavior.

We can rename exitCode to code though if you'd prefer (and exitCodeName to codeName).

[sindresorhus]

Good point. Nah, we can keep it as-is.