Support new Function in @cloudflare/vite-plugin dev module runner

[arthurfiorette]

IM NOT AN AI :)

Hey! I'm in the process of making fastify work in Cloudflare Workers!

A lot of things are working already (fastify startup & plugin lifecycles, schema compilation, I/O serialization...), but that forced me to patch a lot of things on fastify itself, which then forced me to ditch wrangler dev in favor of a full robust vite setup using @cloudflare/vite-plugin.

For my surprise, as soon as I changed to vite, everything blew up again, after some debugging, I discovered the fault was vite: eval at startup is not working during vite dev.

wrangler dev works, wrangler deploy & deployed url works, vite build && wrangler deploy also works, but in vite dev it didn't.

After checking out this repo and clauding around, I realized vite dev server runs userland modules with ModuleRunner instead of passing them directly to workerd native module startup as wrangler dev does.

Luckily, my problem is with AJV that uses new Function (and not eval). So i can use the same hacky workaround vitest-pool-workers does with ensurePatchedFunction.

Obviously eval is not going to be fixed with this PR, If I'm not wrong, eval depends on the local lexical scope, so patching it globally could cause problems. Tbh I don't think a lot of libraries out actually depend on eval and not on new Function.

I'm for sure not an expert in this topic, but it seems the proper fix here would be to architecturally change vite’s development server to feed transformed modules into workerd as real modules instead. I think I can assume it would be a hell of a change, and I KNOW that HMR is not going to like that lol

Tests should be passing. I also removed the fix, reran the tests, and confirmed that they broke again.

---

• Tests
  • Tests included/updated
  • Automated tests not possible - manual testing has been completed as follows:
  • Additional testing not necessary because:
• Public documentation
  • Cloudflare docs PR(s):
  • Documentation not necessary because:

A picture of a cute animal (not mandatory, but encouraged)

[changeset-bot]

🦋 Changeset detected

Latest commit: cf9d55f

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

This PR includes changesets to release 1 package

Name	Type
@cloudflare/vite-plugin	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

[workers-devprod]

Codeowners approval required for this PR:

• @cloudflare/wrangler

Show detailed file reviewers

• .changeset/big-facts-argue.md: [@cloudflare/wrangler]
• packages/vite-plugin-cloudflare/e2e/fixtures/new-function/package.json: [@cloudflare/wrangler]
• packages/vite-plugin-cloudflare/e2e/fixtures/new-function/src/index.ts: [@cloudflare/wrangler]
• packages/vite-plugin-cloudflare/e2e/fixtures/new-function/vite.config.ts: [@cloudflare/wrangler]
• packages/vite-plugin-cloudflare/e2e/fixtures/new-function/wrangler.jsonc: [@cloudflare/wrangler]
• packages/vite-plugin-cloudflare/e2e/new-function.test.ts: [@cloudflare/wrangler]
• packages/vite-plugin-cloudflare/src/workers/runner-worker/tests/env.spec.ts: [@cloudflare/wrangler]
• packages/vite-plugin-cloudflare/src/workers/runner-worker/env.ts: [@cloudflare/wrangler]
• packages/vite-plugin-cloudflare/src/workers/runner-worker/module-runner.ts: [@cloudflare/wrangler]

[jamesopstad]

Hi @arthurfiorette. Thanks for looking into this!

Luckily, my problem is with AJV that uses new Function (and not eval). So i can use the same hacky workaround vitest-pool-workers does with ensurePatchedFunction.

The problem with this approach is that it also permits using new Function() within a request context, which is forbidden and will error in production. new Function() should only be permitted during the startup phase of a Worker and this functionality is enabled by the compatibility_date or allow_eval_during_startup compatibility flag. As you've realised, this doesn't currently work in vite dev. I think it would be worse to fix this in dev though by allowing features that would break in production.

I'm for sure not an expert in this topic, but it seems the proper fix here would be to architecturally change vite’s development server to feed transformed modules into workerd as real modules instead. I think I can assume it would be a hell of a change, and I KNOW that HMR is not going to like that lol

Yeah, the problem with this is that you would lose a lot of the benefits of Vite i.e. HMR and not needing to restart workerd on every code change.

We are planning to fix the inaccuracies that come from using Vite's transformed modules. #9489 is another related issue. It's quite complicated though and will most likely require some changes to workerd to enable emulating real modules more accurately in dev.