fix(ext/node): add missing release property to node's process

[yardenshoham]

Docs: https://nodejs.org/api/process.html#processrelease

import process from 'node:process';
console.log(process.release);
// outputs:
// {
//   name: "node",
//   sourceUrl: "https://nodejs.org/download/release/v18.12.1/node-v18.12.1.tar.gz",
//   headersUrl: "https://nodejs.org/download/release/v18.12.1/node-v18.12.1-headers.tar.gz"
// }

• Fixes npm incompatibility due to process.release.name #18870

[yardenshoham]

I made it use deno for the name and not node. Also, I used Deno's source URL instead of node's, is that fine?

[yardenshoham]

I wonder if we should set name to node to be fully compatible with node. But that feels like lying

[rajsite]

I wonder if we should set name to node to be fully compatible with node. But that feels like lying

@yardenshoham if it was changed to 'deno' that wouldn't address the original issue I filed which was an exisiting npm: scoped library using the process.release === 'node' to detect environment (browser vs worker vs node). The node check would still fail (which makes that commonjs library not usable in Deno in this case).

Guess it depends on deno's intent with the node: namespace. If the intention is strictly to be a compatibility layer then I'd expect process.release to report node. Seems like Deno's intent is exisiting npm libraries can be used in Deno without updates. Not to make the node: namespace a first class API target, i.e. the browser API's are Deno's first class APIs that users should be encouraged to target, so would only focus node: on compatibility.

If I was a library author trying to support Deno and Node and needed conditional logic / environment specific behaviors then I'd be checking for the Deno global existence. But everything under the node: namespace would be trying to emulate the node environment as closely as possible. i.e. don't want to encourage deno authors to be writing against the node: namespace so Deno wouldn't expose deno-specific behavior there.

[rajsite]

I wonder if we should set name to node to be fully compatible with node. But that feels like lying

Or to put it another way. I think for node: and npm: scoped packages Deno actively wants to lie and make it look like a normal node environment to the modules.

[yardenshoham]

I agree, I changed it

[kt3k]

name: node makes sense to me as its for compatibility.

@yardenshoham Can you run ./tools/format.js to fix format issue in CI?

[yardenshoham]

It failed on a flaky test

[lino-levan]

LGTM

[kt3k]

LGTM. Thanks!