Use workerd node:process v2 when available

[vicb]

This PR enabled using workerd node:process v2 when it is enabled (by flag or date).

It depends on the implemntation being available:

• implemented in Remove experimental for node:process workerd#4960
• releases in workerd v1.20250904.0

A few notes:

This PR still fails the remote tests as the v2 changes have not reached production yet.

Some of the v2 APIs are undefined.

For that reason we still need an hybrid polyfill pulling their implementation from unenv. Otherwise the following code might break:

import { process } from "node:process";

// This would break with v2 as `process.release` is `undefined.
console.log(process.release.name);

Because we have to use an hybrid polyfill anyway, we keep all the APIs that are implemented in unenv and missing from workerd:

• _... APIs (_channel, _debugEnd, ...)
• some other APIs as addListener, assert, ...

addListener, assert, ... are not all documented on nodejs.org and a few are deprecated. But they all are available for Node 22.16.0 (tested in the REPL).

Maybe we can refine and better handle deprecated APIs now that we have a dedicated workerd flag. Comments welcome.

@petebacondarwin @guybedford could you please review the PR, the API surface is quite large and having more eyes would be helpful.

---

• Tests
  • Tests included
  • Tests not necessary because:
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because: will be documented by the runtime team
• Wrangler V3 Backport
  • Wrangler PR:
  • Not necessary because: unenv changes are not backported

[changeset-bot]

🦋 Changeset detected

Latest commit: 0782e55

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@cloudflare/unenv-preset	Patch
@cloudflare/vite-plugin	Patch
wrangler	Patch
@cloudflare/vitest-pool-workers	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

create-cloudflare

npm i https://pkg.pr.new/create-cloudflare@10577

@cloudflare/kv-asset-handler

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@10577

miniflare

npm i https://pkg.pr.new/miniflare@10577

@cloudflare/pages-shared

npm i https://pkg.pr.new/@cloudflare/pages-shared@10577

@cloudflare/unenv-preset

npm i https://pkg.pr.new/@cloudflare/unenv-preset@10577

@cloudflare/vite-plugin

npm i https://pkg.pr.new/@cloudflare/vite-plugin@10577

@cloudflare/vitest-pool-workers

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@10577

@cloudflare/workers-editor-shared

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@10577

wrangler

npm i https://pkg.pr.new/wrangler@10577

commit: 0782e55

[guybedford]

I believe that in most of the cases where unenv is providing an implementation of a function like process.binding() and where we are providing undefined - the implementation is simply a throwing stub. Simply copying over the throwing stub should be just a couple of lines and might get far to enabling a non-hybrid approach.

For undocumented APIs, I notice _debugEnd is implemented by Bun but not Deno. Do we definitely need these?

For non-function bindings, like process.release - having an upstream issue to track their support would be a huge help. Happy to fill gaps as necessary as well.

[vicb]

I believe that in most of the cases where unenv is providing an implementation of a function like process.binding() and where we are providing undefined - the implementation is simply a throwing stub. Simply copying over the throwing stub should be just a couple of lines and might get far to enabling a non-hybrid approach.

When you say "Simply copying over the throwing stub [...]" do you mean copying the implementation to workerd?

If you rather mean copying the implementation to the unev preset in this repo then that would still be an hybrid polyfill and I don't really see the point?

For undocumented APIs, I notice _debugEnd is implemented by Bun but not Deno. Do we definitely need these?

I agree that the likeness those _... APIs are used is low but we have no way to definitely rule out that they are not.
And because we need an hybrid polyfill anyway there should be no good reason to remove them?

For non-function bindings, like process.release - having an upstream issue to track their support would be a huge help. Happy to fill gaps as necessary as well.

Sorry, I'm not exactly sure where you'd want to create the issue and what the content should be. Feel free to start someone and I'll contribute if needed.