Replies: 6 comments 9 replies
-
I started to experimenting with workerd/miniflare in Overall approach and code doesn't look so different from my previous one with vite runtime https://github.com/hi-ogawa/vite-plugins/tree/main/packages/vite-node-miniflare, but regarding the usability of current environment API, I have a few comments:
I haven't tested server hmr yet, but I plan to continue experiment on that later. |
Beta Was this translation helpful? Give feedback.
-
This is a feedback about a minor cosmetics of logging. Currently, simple SSR setup (like the one in a playground) shows somewhat puzzling logs: pnpm -C playground/environment-react-ssr dev
# after changing a shared file src/root.tsx
3:03:13 PM [vite] page reload src/root.tsx
3:03:13 PM [vite] page reload src/root.tsx
[vite] program reload On my react-server example with client hmr plugin, it gets more complex: pnpm -C examples/react-server dev
# initial log from two server environments
[vite] connected.
[vite] connected.
# after changing a shared file
3:13:02 PM [vite] hmr update /home/hiroshi/code/personal/vite-environment-examples/examples/react-server/src/routes/_client.tsx
3:13:02 PM [vite] page reload src/routes/_client.tsx
[vite] program reload In "two Vite servers" demo, I have {
customLogger: createLogger(undefined, {
prefix: "[react-server]",
allowClearScreen: false,
}),
} 3:13:02 PM [react-server] page reload src/routes/test/page.tsx Is there a way to add log prefix like this for new environments? or maybe can each log have a prefix of |
Beta Was this translation helpful? Give feedback.
-
When running
I haven't dive into the code yet. For now, I made a reproduction here #16426 since you might know something. |
Beta Was this translation helpful? Give feedback.
-
Can service workers be a supported environment too? I'd like to build an offline web app almost the same as an online one. If server side rendering can be bundled to be used as service worker side rendering then an offline web app doesn't need to bundle and run most (if any) JavaScript in the document scope. |
Beta Was this translation helpful? Give feedback.
-
This is awesome to see. Wanted to ask about how something like injecting new globals or CSPs would work to emulate other environments, like extensions or a Kiosk mode. It'd be great to be able to add APIs not normally exposed in-browser and that may required server-side backing (like |
Beta Was this translation helpful? Give feedback.
-
hey! 👋 i was building a really simple spa with solid, and i wanted to change the but i wasn't really able to find an easy and simple way to do this at all!! perhaps customizing the behavior of vite's dev and build feel so difficult because the module resolution is so tightly coupled to your entry file, and perhaps this coupling is exactly what makes implementing ssr with vite so complicated in the first place. I am not quite settled on the correct way to solve this, but one of my ideas is perhaps the ability to set a jsx file (with exports) as your entry file, then write a plugin that has access to those exports and returns an html string? not really the most happy with that though, im curious what ideas other people have! At the end of the day, I would like basic ssg functionality (at least in solid) to be easily implementable by end users in your own 5-line vite plugin. |
Beta Was this translation helpful? Give feedback.
-
We decided to release the Environment API branch as
vite@6.0.0-alpha.x
(we'll continue regularly releasing new alpha patches).The changes started by the Runtime API are now prompting a complete review of the way Vite handles environments (client, SSR, workerd, etc). We were originally going to release this branch as
vite@5.3.0-alpha.0
but the changes are now too big for a minor so we're going to start working on the next major directly with it. We're probably going to have ~2 months of alpha period and once we feel confident with the stability of the new APIs, we'll kick the beta.If you are building a framework or are working in a Runtime (like the Cloudflare team), the next months are going to be very important to get the APIs right and serve as the base for the next iteration. We're thinking on lifting Vite's responsibilities to be able to share more in the ecosystem. For example, we're introducing the concept of a
ViteBuilder
that lets frameworks orchestrate all the environment builds they need to get a singlevite build
command to build the whole app. This means changing our stance on the "framework-as-a-plugin" pattern (SvelteKit, Remix, QwikCity, etc), and making it a first class pattern from Vite 6 forward.Check out the current Environment API docs and give us feedback. This discussion is a good place to gather it, please share your impressions and PoCs as you test.
If you think someone you know would be interested in helping us testing and creating prototypes (Workerd framework-agnostic integrations, RSC, etc), please contact them so they can get involved.
Resources:
Previous discussions:
History:
Check out @antfu's Dev SSR on Nuxt post, explaining @pi0's Dev Bundler idea that led to the creation of vite-node. Anthony used vite-node to as the engine of Vitest. After revamping it, @sheremet-va added a revised version of vite-node in Vite Core in Vite 5.1. The Environment API is a new iteration, deeply integrating the features vite-node provided in Vite's API.
Beta Was this translation helpful? Give feedback.
All reactions