Reducing inconsistency when developing for non-Node environment by emulating the environment

[sapphi-red]

Inconsistency between dev and build when developing for non-Node environment has been a weak point for Vite.

For instance,

• Accessing environment specific APIs is not possible out-of-the-box
  • Cloudflare KV
    • this is possible to polyfill on meta-framework side or user side by using @miniflare/kv or the Miniflare#get*()
  • URLPattern
    • this is also possible to polyfill
• Accessing Node.js specific features doesn't throw an error
  • global variables like global, process, Buffer
  • code generation related features like eval, new Function

Approach

Use node:vm and vite-node to execute the code.
Add ssr.environment that accepts ViteEnvironment type.

PoC: https://github.com/sapphi-red/vite-envs

Pros

• Universal support
  • You can use this to develop a library for edge envs.
    • vite-node -e vercel-edge ./src/index.ts
  • Vitest support would be there by just creating an environment package for Vite
• Performant HMR / startup
  • same as Vite in this approach the code won't be bundled
• Can catch errors that happen when deployed like accessing Node.js specific features

Cons

• Developing an environment package takes time if there's many environment specific APIs

Deno based environments

There are environments based on Deno. For example, Deno Deploy, Netlify edge functions.

For those environments, I guess a similar approach can be used by running Vite on Deno.

Alternatives

Running in the actual environment

vite-node has the ability to run the server (the part that does the code transform) and the client (the part that does the execution). For example, Vitest runs the client in worker threads.
So instead of running in node:vm, we can run the client in the actual environment (e.g. workerd, deno).
The client uses some Node.js modules but I guess it's possible to remove them conditionally.

The problem is that the client somehow needs to use eval or something similar, but it's not allowed in some environments (workerd).

In the case of workerd, I guess it's possible by forking it (related code). But it seems Cloudflare working on something similar, so it might be feasible in the future.

Questions

Should runModule and selectModule be included in ViteEnvironmentInfo?

runModule and selectModule are the properties I added here.
runModule is a function that receives the Module and request and calls the handler with some context values depending on the environment (Cloudflare, Vercel).
selectModule is a function that receives the request and returns the path of the module that should be executed (Cloudflare, Vercel).

I added these functions to make it easier to implement meta-frameworks. @vite-env/standalone package is how I expect meta-frameworks to use these functions.

I think runModule can fit in Vite but selectModule might be too much.

How to support rewriting Node module imports?

Some environments support a small set of Node.js modules (e.g. Cloudflare, Vercel).

Because import cannot be used inside node:vm(vm.runInContext) and we shouldn't expose require, we'll need to rewrite import foo from 'node:foo' into const foo = globalThis._viteEnvNode.foo. This is possible by resolveId + load hook but I wonder if it's better to include in the ViteEnvironment type. I'm leaning not to include it.

// example plugin that rewrites the import
const plugin = {
  name: 'e',
  resolveId(id) {
    if (id.startsWith('node:')) return `\0e:${id.slice('node:'.length)}`
  },
  load(id) {
    if (!id.startsWith('\0e:')) return

    const name = id.slice('\0e:'.length)
    return {
      code: `export default _viteEnvNode[${JSON.stringify(name)}]`,
      syntheticNamedExports: true
    }
  }
}

Should Vite use a Web Standard-based middleware instead of Node middleware?

Web Standard-based middleware means a middleware that uses Request and Response from Fetch Standard spec (I'm not sure if there's a widely used term for this). Node middleware means a middleware that uses http.IncomingMessage and http.ServerResponse. Web Standard-based middlewares can be easily used in any environments. Non-node environment natively supports them and there's some packages that can convert Node middlewares into Web Standard-based middlewares.

The POC runs a separate server alongside with the Vite server, because I wasn't able to convert Node middlewares into Web Standard-based middlewares. (related code 1, related code 2) If Vite uses a Web Standard-based middleware, we can stop doing this separate server thing.

Or another way to solve this is to convert Node middlewares into Web Standard-based middlewares. I found @fastly/http-compute-js does this but there's much incompatibility and I guess it's difficult to achieve.

References

• Make dev server SSR work with non-node runtime #10770
• Support SSR in the edge runtime with Vite dev server QwikDev/qwik#1984
• https://kit.svelte.dev/docs/adapter-cloudflare#bindings-testing-locally
• Cannot access to the KV binding with Cloudflare Pages withastro/astro#8347 (comment)
• https://rakkasjs.org/guide/cloudflare-workers#:~:text=Cloudflare%20Workers%2Dspecific,CLOUDFLARE_DB%20during%20development%3A
• https://rakkasjs.org/guide/vercel#:~:text=Worker%2Dspecific%20APIs,for%20Vercel%20Edge.

[sapphi-red]

Here's a POC for the alternative "Running in the actual environment". This doesn't work yet as the vite-node client depends on Node.js builtin modules.

https://github.com/sapphi-red/vite-envs/tree/run-in-workerd

[dario-piotrowicz]

@sapphi-red quick note about workerd and eval, a new binding for that has recently been added, so it should indeed be possible to use eval locally now 🙂 (cloudflare/workerd#1338, cloudflare/workers-sdk#4322)

[sapphi-red]

That's great! I see that unsafe.eval and unsafe.newFunction have been implemented, would you consider implementing unsafe.newAsyncFunction? I guess I can workaround by doing const AsyncFunction = async function () {}.constructor; inside unsafe.eval though.

[dario-piotrowicz]

@sapphi-red I'm sorry I just now saw your reply 😓, let me check with the team if newAsyncFunction could potentially be added 👍

[jasnell]

@sapphi-red I certainly think that an unsafe.newAsyncFunction(...) ought to be possible. I'll look into it.

[yusukebe]

Hi @sapphi-red!

As the creator of Hono and a member of Cloudflare, I'm very curious about this issue.

At Hono, we are developing @hono/vite-dev-server to enable the development of Hono applications with Vite. Although it seems specific to Hono, any fetch-based app should work. This uses @hono/node-server inside to convert http.IncomingMessage and http.ServerResponse to the Web Standard Request and Response. This approach is the same as one of the ideas in your PoC.

I believe the optimal solution for this issue would be to handle it within Vite itself, rather than individually across frameworks. We'd like to support you. Perhaps we could use Hono as a test case. Thanks.