Fix deno node:process execPath compatibility

[w3cj]

• When running execa from Deno the following error occurs:

The "nodePath" option must be a string or a file URL: /Users/username/deno/bin/deno.

• Traced this call back to here: https://github.com/sindresorhus/execa/blob/main/lib/methods/node.js#L29
  • nodePath defaults to execPath from node:process
  • execPath in the Deno process pollyfill is a special object, not just a string: https://github.com/denoland/deno/blob/main/ext/node/polyfills/process.ts#L344
• The check for string in lib/arguments/file-url.js fails, because execPath is not a string

Note: This issue currently occurs in the Nuxt CLI when trying to run with Deno: denoland/deno#25779

Simple reproduction (run this with Deno v2):

import { execa } from "npm:execa";

const result = await execa("ls");
console.log({ result });

[ehmicky]

Looks good to me!

Thanks a lot @w3cj for making this PR and adding information in the PR comment and the code comment. 🙏

Should we merge and release @sindresorhus?

[sindresorhus]

Should we merge and release @sindresorhus?

Go ahead 👍

[ehmicky]

I have a few additional thoughts.

---

First, what Deno is doing here is quite hacky (in their own words). Using an object like this where a string is expected is probably going to create quite many issues: not just that one solved in this PR, but probably with other projects. That being said, I do understand why they might need to do that (that's because process.execPath requires Deno permissions, i.e. must be lazily computed).

I am wondering whether it would be slightly safer to convert those to a string instead?

export const safeNormalizeFileUrl = (file, name) => {
	const fileString = normalizeFileUrl(normalizeDenoExecPath(file));
	// ...
}

// In Deno node:process execPath is a special object, not just a string:
// https://github.com/denoland/deno/blob/f460188e583f00144000aa0d8ade08218d47c3c1/ext/node/polyfills/process.ts#L344
const normalizeDenoExecPath = file =>  isDenoExecPath(file)
	? file.toString()
	: file

const isDenoExecPath = file => typeof file !== 'string'
	&& file
	&& Object.getPrototypeOf(file) === String.prototype;

---

Then, the following syntax needs to be taken into account too:

execa(...).pipe(process.execPath, ...)

Right now, it relies on the following check, which would not work with Deno:

execa/lib/pipe/pipe-arguments.js

Lines 59 to 67 in d3a146e

	if (typeof firstArgument === 'string' || firstArgument instanceof URL) {
	if (Object.keys(boundOptions).length > 0) {
	throw new TypeError('Please use .pipe("file", ..., options) or .pipe(execa("file", ..., options)) instead of .pipe(options)("file", ...).');
	}
	const [rawFile, rawArguments, rawOptions] = normalizeParameters(firstArgument, ...pipeArguments);
	const destination = createNested(mapDestinationArguments)(rawFile, rawArguments, rawOptions);
	return {destination, pipeOptions: rawOptions};
	}

Adding some ... || isDenoExecPath(firstArgument) should be enough to fix this.

---

Finally, we should add automated tests for the following cases:

• execa(process.execPath, ...)
• execa(...).pipe(process.execPath, ...)
• execaNode(...)

When process.execPath is like Deno. Instead of running with Deno, we could monkey patch process.execPath to make it look like Deno.

Ideally, we would run the automated tests with Deno, but I don't think Deno compatibility is one of our goals right now since that's quite a big requirement for a project like Execa. But that PR is ok though since it is a rather simple fix.

If you need help with the automated tests, please let me know.

---

What do you think @w3cj?

[w3cj]

Yeah that seems reasonable. I wasn't quite sure what else in the code base would be effected. I should have some time to work on this later today.

[w3cj]

Updated safeNormalizeFileUrl as mentioned and added tests. Please let me know if this is what you had in mind.

[ehmicky]

That's perfect, thanks @w3cj!

[ehmicky]

Released in 9.4.1.