Remove node_compat flag from C3 templates that use Vitest Pool Workers

[andyjessop]

Fixes #000.

Removes the need to add nodejs_compat flag in C3 templates just to use Vitest Pool Workers. Vitest Pool Workers will now inject the flag if it doesn't exist.

• Tests
  • TODO (before merge)
  • Tests included
  • Tests not necessary because: Covered by existing
• E2E Tests CI Job required? (Use "e2e" label or ask maintainer to run separately)
  • I don't know
  • Required
  • Not required because:
• Public documentation
  • TODO (before merge)
  • Cloudflare docs PR(s): Add better messaging on Vitest Pool Workers and nodejs_compat cloudflare-docs#18495
  • Documentation not necessary because:

[changeset-bot]

🦋 Changeset detected

Latest commit: 7921997

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

This PR includes changesets to release 2 packages

Name	Type
@cloudflare/vitest-pool-workers	Minor
create-cloudflare	Minor

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

[github-actions]

A wrangler prerelease is available for testing. You can install this latest build in your project with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12371250417/npm-package-wrangler-7388

You can reference the automatically updated head of this PR with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/7388/npm-package-wrangler-7388

Or you can use npx with this latest build directly:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12371250417/npm-package-wrangler-7388 dev path/to/script.js

Additional artifacts:

wget https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12371250417/npm-package-cloudflare-workers-bindings-extension-7388 -O ./cloudflare-workers-bindings-extension.0.0.0-vf9826e061.vsix && code --install-extension ./cloudflare-workers-bindings-extension.0.0.0-vf9826e061.vsix

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12371250417/npm-package-create-cloudflare-7388 --no-auto-update

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12371250417/npm-package-cloudflare-kv-asset-handler-7388

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12371250417/npm-package-miniflare-7388

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12371250417/npm-package-cloudflare-pages-shared-7388

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12371250417/npm-package-cloudflare-vitest-pool-workers-7388

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12371250417/npm-package-cloudflare-workers-editor-shared-7388

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12371250417/npm-package-cloudflare-workers-shared-7388

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12371250417/npm-package-cloudflare-workflows-shared-7388

Note that these links will no longer work once the GitHub Actions artifact expires.

---

[email protected] includes the following runtime dependencies:

Package	Constraint	Resolved
miniflare	workspace:*	3.20241205.0
workerd	1.20241205.0	1.20241205.0
workerd --version	1.20241205.0	2024-12-05

Please ensure constraints are pinned, and miniflare/workerd minor versions match.

[Cherry]

This is incredibly interesting!

Won't this potentially cause issues where a project could work during tests (if it does nodejs_compat stuff) but then fail during deploy or in prod, creating a different and now hard to debug environment?

Perhaps simply doing nodejs_compat + no_nodejs_compat_v2 would make more sense, to reduce the amount of cruft added to workers by default (#7108), but avoid the environment differences?

[andyjessop]

@Cherry thanks again for the thoughtful contribution. I think this issue is multi-layered. Your solution of nodejs_compat + no_nodejs_compat_v2 is a good technical solution but this isn't just about bundle size. One thing we're very concerned with is moving users towards web standards and away from reliance on Node.js APIs. Having it enabled by default is messaging that we would like to avoid.

Won't this potentially cause issues where a project could work during tests (if it does nodejs_compat stuff) but then fail during deploy or in prod, creating a different and now hard to debug environment?

Yes, this is a concern, for sure. We hope that we can minimise any potential problems by making it very difficult to deploy bad code. For example, we have fail safe checks at build and also at deploy time (where there is a remote check that the code is able to be run by workerd). Edge-cases are probably dynamic imports of node APIs and usage of globals like Buffer.

[DaniFoldi]

I think unfortunately enabling nodejs_compat_v2 by default would break opentelemetry libs' platform detection - and possibly many others. Checking for globalThis.Buffer is still pretty common in libraries :/

[petebacondarwin]

Pedantic NIT 😄

Suggested change

	runnerWorker.compatibilityFlags.push("nodejs_compat");
	runnerWorker.compatibilityFlags.push("no_nodejs_compat_v2");
	runnerWorker.compatibilityFlags.push("nodejs_compat", "no_nodejs_compat_v2");

[andyjessop]

Thanks, I'm not really with it this morning...