Stabilizing the environment API

[sapphi-red]

• Broad API Design Checks
  • Does the current "Environment" + "Environment Factory" abstraction work?
  • What does "Environment" mean?
  • Does hotUpdate hook look fine? (may be we can stabilize this one separately from the env API)
  • Per-environment plugins: How should these be handled? How did you handle?
  • Does "DevEnvironment Communication Levels" concept make sense?
  • Are there anything difficult when writing environment factories?
  • Can we deprecate server.ssrLoadModule now? Are there any blockers?
• defaulting to not inheriting top-level config for non-client environment vite#21336
• What is needed additionally for the stabilization?

[jamesopstad]

One question to add: Do we need the FetchableDevEnvironment API? It's interesting to me that neither the Cloudflare or Nitro plugins are using this. Are others?

[sheremet-va]

One question to add: Do we need the FetchableDevEnvironment API? It's interesting to me that neither the Cloudflare or Nitro plugins are using this. Are others?

I don't think we got any feedback on the usage. If no one is interested in the common fetchable interface anymore, then there is no use case for it.

[sapphi-red]

nitro does seem to have a similar environment, but it just doesn't use the API.
https://github.com/nitrojs/nitro/blob/5ea3e153dbdbc5a6c6fa56d868179c7976a886ea/src/build/vite/dev.ts#L42

[magne4000]

@jamesopstad I'm curious, what made you base your custom env upon DevEnvironment instead of FetchableDevEnvironment?

[jamesopstad]

@jamesopstad I'm curious, what made you base your custom env upon DevEnvironment instead of FetchableDevEnvironment?

We started implementing it before FetchableDevEnvironment existed but we did at one point have a dispatchFetch method like FetchableDevEnvironment. We removed it because we were no longer using it and didn't want others to use it either.

We try to emulate the production environment as much as possible in dev, including how requests are routed in relation to assets and features like run_worker_first. Adding both the environments and the middleware that dispatch to them enables us to do this. Allowing other plugins to dispatch to the environment directly hasn't been necessary and would bypass this handling.

[jamesopstad]

Sharing a common pattern that we see across frameworks. The framework provides a default server middleware but skips it if the environment is not runnable. This enables another plugin to define a different implementation for the environment and to provide the middleware itself in these cases.

Examples

TanStack Start
React Router
Astro

[sapphi-red]

Thinking of #1 (comment), I wonder if the interface for the meta-frameworks should be a middleware rather than RunnableDevEnvironment.runner.import / FetchableDevEnvironment.dispatchFetch.
If the RunnableDevEnvironment satisfies the FetchableDevEnvironment interface (vitejs/vite#22154), would that also work?

[danielroe]

One question to add: Do we need the FetchableDevEnvironment API? It's interesting to me that neither the Cloudflare or Nitro plugins are using this. Are others?

I think we would need this for Nuxt. it does have a limitation I'd like to discuss: it forces the bundle into a single route as opposed to allowing to fetch from different 'endpoints' (matching different files in an environment). This is problematic for tree-shaking.

[serhalp]

Re-sharing this here as I think they're valuable questions to answer as part of stabilization: vitejs/vite#16358 (reply in thread)