@guybedford worked on the native implementation of node:process v2.

When we tried to enabled the v2 module to replace the unenv when ran into an issue and had to revert the PR.

The root cause of the issue is that v2 is more true to the Node implementation and Astro started to think workerd is Node (because of process.toString()):

const isNode = typeof process !== "undefined" && Object.prototype.toString.call(process) === "[object process]";

Astro was then using a Node code path in the rendering, building the response from an AsyncIterable.

workerd has a known issue when building a Response from an AsyncIterable.

@jasnell initally fixed the issue in cloudflare/workerd#5476 (gated by the fetch_iterable_type_support compat flag). This first implementation was not fully functional and James created a follow up change (gated by the fetch_iterable_type_support_override_adjustment compat flag).

On Feb 3, 2026, I ran the Astro test suite (main branch of the repo)

• with the latest NPM release of wrangler/vite-plugin -> all tests pass as expected
• with a custom version of wrangler enabling process v2 -> quite a few tests started to fail as expected
• verified that adding both the flags mentioned above fixes the failures

So I think a reasonable plan would be to enable native process v2 if all of the following conditions are met:

• compatibility_date >= 2025-09-15 or process v2 enabled by flag (enable_nodejs_process_v2)
• both fetch_iterable_type_support and fetch_iterable_type_support_override_adjustment are active (explicitly specified or implied)

When the conditions are not met, we'll keep using the unenv polyfill - it is an hybrid polyfill, that is most of the implementation comes from workerd but some of the APIs are polyfilled.

Any thought about the plan?

It took some time and many people to come with this plan. Kudos to @guybedford @jasnell @danlapid @ascorbic @matthewp @ematipico @petebacondarwin and probably more (sorry if I missed your name) for the help.