Review requested:

• @nodejs/modules

Windows test failures are due to a failed dependency install (unrelated to the change in this PR):

Error retrieving packages from source 'https://community.chocolatey.org/api/v2/':
 Could not connect to the feed specified at 'https://community.chocolatey.org/api/v2/'. Please verify that the package source (located in the Package Manager Settings) is valid and ensure your network connectivity.
nasm not installed. The package was not found with the source(s) listed.
 Source(s): 'https://community.chocolatey.org/api/v2/'
 NOTE: When you specify explicit sources, it overrides default sources.
If the package version is a prerelease and you didn't specify `--pre`,
 the package may not be found.
Please see https://docs.chocolatey.org/en-us/troubleshooting for more
 assistance.

Chocolatey installed 0/1 packages. 1 packages failed.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Failures
 - nasm - nasm not installed. The package was not found with the source(s)

So this has an effect of allowing sending any kind of object that can coerce to a string as the return value. I would prefer we didn't do this since it would make future changes to the API hard since virtually everything converts to a string.

How would adding new URL(url) allow returning any object? It will explode for anything that is not a url string or stringifiable to a url string. We could maybe need to worry about something like an anchor element, in which case I could check both typeof url !== 'string' and new URL(url).

@JakobJingleheimer I'd agree it must turn into a URL compatible string, but anything could be that. For example a Buffer can do that. And I don't want a Buffer/SharedArrayBuffer to be able to do that.

Would my proposal to restore the if (typeof url === 'string') check in addition to the new new URL(url) suffice?

sure, checking both seems fine. I'm trying to think of cases where people would even want to return a non-URL?? Can't think of any off the top of my head so it seems fine

They're currently required to return a url, no?

@JakobJingleheimer yes, it currently is supposed to check for a stringified URL as a return

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

@guybedford any thoughts, concerns, or objections?

Landed in dbc6e39