[cloudflare] Generated wrangler config specifies nodejs_compat, which workerd rejects for compatibility dates from 2026-08-04
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 11.2k
- Forks
- 899
- Avg merge
- 2d 24m
- Merged PRs (30d)
- 40
Description
Environment
nitropack2.13.4 (also reproduces via Nuxt 4.5.2 / nuxi 3.37.0)workerd>= 1.20260804.x (shipped in recentwranglerreleases)- Presets: both
cloudflare_pagesandcloudflare_module
Describe the bug
As of workerd 1.20260804.x, the nodejs_compat and nodejs_compat_v2 compatibility flags are enabled by default from compatibility date 2026-08-04 ($compatEnableDate("2026-08-04") in compatibility-date.capnp).
Once a flag becomes the default, specifying it explicitly is a hard error in workerd — not a warning:
✘ [ERROR] service core:user:my-app: The compatibility flag nodejs_compat became the default as of 2026-08-04 so does not need to be specified anymore.
✘ [ERROR] The Workers runtime failed to start. There was likely a problem with the workerd binary or your configuration.
Nitro's Cloudflare preset adds nodejs_compat unconditionally to the wrangler config it generates, so any Nitro project with compatibility_date >= 2026-08-04 fails to start:
https://github.com/nitrojs/nitro/blob/main/src/presets/cloudflare/utils.ts
if (nitro.options.cloudflare?.nodeCompat) {
// ...
} else {
compatFlags.add("nodejs_compat");
compatFlags.add("no_nodejs_compat_v2");
}
}
wranglerConfig.compatibility_flags = [...compatFlags];
Because this config is written into the build output and wrangler is pointed at it through a .wrangler/deploy/config.json redirect, it overrides the user's own wrangler.jsonc:
Using redirected Wrangler configuration.
- Configuration being used: "dist/_worker.js/wrangler.json"
- Original user's configuration: "wrangler.jsonc"
- Deploy configuration file: ".wrangler/deploy/config.json"
So users cannot work around this from their own wrangler config — removing nodejs_compat there has no effect, since Nitro re-adds it at build time.
Note also that enableNodeCompat() turns nodeCompat on automatically whenever deployConfig is set, so this affects projects that never explicitly opted into Node.js compatibility.
Reproduction
pnpm create cloudflare@latest my-nuxt-app --framework=nuxt --platform=workers
cd my-nuxt-app
pnpm run preview
C3 scaffolds with today's date as compatibility_date (>= 2026-08-04) and does not specify nodejs_compat. The build succeeds; the dev server fails to boot with the error above.
Suggested fix
Only add nodejs_compat when the resolved compatibility_date is before 2026-08-04; from that date the flag is implicit and must be omitted:
const NODEJS_COMPAT_DEFAULT_ON_DATE = "2026-08-04";
if (wranglerConfig.compatibility_date < NODEJS_COMPAT_DEFAULT_ON_DATE) {
compatFlags.add("nodejs_compat");
}
compatFlags.add("no_nodejs_compat_v2");
(Plain string comparison is safe for YYYY-MM-DD dates.)
no_nodejs_compat_v2 is unaffected — disable flags are not rejected — so it can still be added unconditionally if that is the intended behaviour.
It would also be worth reviewing the nodejs_compat_v2 branch just above, since that flag has the same 2026-08-04 default-on date and will hit the identical error.
Additional context
We have quarantined our Nuxt end-to-end tests in cloudflare/workers-sdk while this is outstanding, and are tracking it on our side in https://github.com/cloudflare/workers-sdk/issues/15146. Happy to help review or test a fix.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in src/presets/cloudflare/utils.ts and inspect the nodejs_compat and nodejs_compat_v2 branches that assemble the generated Wrangler configuration. Reproduce the failure with the provided Cloudflare/Nuxt commands, then verify that configurations with compatibility_date 2026-08-04 or later omit the default-on flags while earlier dates retain the needed compatibility flag.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- cloud, devops
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 76/100