Replies: 22 comments 60 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.
-
|
@patak-dev Thanks for the update. Asynchronous Expanding on my previous 2nd comment, I'd like to disable this vite/packages/vite/src/node/optimizer/index.ts Lines 781 to 786 in 7254175
@sheremet-va Yeah, I didn't mean to be an environment API feedback, but just wanted to mention as a general caveat for people trying workerd. Well, I thought so, but now looking at mrbbot's vitest integration, he seems to figure out a way around it by implementing Either way, it's a custom runtime side constraints, so I don't think Vite side needs to do anything for this. |
Beta Was this translation helpful? Give feedback.
-
Regarding environment agnostic SSR https://deploy-preview-16089--vite-docs-main.netlify.app/guide/api-vite-environment.html#environment-agnostic-ssr, the plugin is still registering middleware automatically, but the main feature is mostly moved to Currently I organized API in this way: WorkerdDevEnvironmentexport type WorkerdDevEnvironment =
DevEnvironment & {
api: {
dispatchFetch: (entry: string, request: Request) => Promise<Response>
}
}
export function createWorkerdDevEnvironment(
server: ViteDevServer,
name: string,
// allow miniflare customization inspired by vitest pool
// https://developers.cloudflare.com/workers/testing/vitest-integration/configuration/
workerdOptions: {
miniflare: { ... },
wrangler: { configPath?: string }
}
): Promise<WorkerdDevEnvironment>;Then configureServer{
configureServer(server) {
const devEnv = server.environments["workerd"] as WorkerdDevEnvironment;
const nodeHandler = webHandlerToNodeHandler(
(req) => devEnv.api.dispatchFetch(someEntry, req),
);
return () => {
server.middlewares.use(nodeHandler);
};
},
}Also thanks to cloudflare team's effort on Vitest pool, there are new features in wrangler such as All that said, how workerd feature is exposed to main vite process side is still only a minimal request handler, so the situation might not change drastically in terms of easy of existing complex frameworks to integrate. One thing I plan to look at next is whether it's possible to implement something similar to "magic proxy" cloudflare/miniflare#639 so that main vite process can transparently import modules from workerd just like |
Beta Was this translation helpful? Give feedback.
-
|
@sheremet-va I implemented Actually I'm not sure if it's correct (I haven't tested custom event), but it feels like it's mostly a boilerplate. Is this something like Vite can provide builtin utility like transport? |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, we can implement a separate transport option for HMR to hide the boilerplate. |
Beta Was this translation helpful? Give feedback.
-
This should now work without |
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 reloadOn 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 reloadIn "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.tsxIs 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.
-
|
Good point. I think we should do this by default. The logger has a prefix option defaulting to @sheremet-va I see the |
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.
-
|
I think that could work. I was also thinking about Web Workers. Maybe we should also implement them using environments. We have some issues right now with the way they are implemented that could be cleaned up with them. If you have some time to try out the alpha, that would be great to inform our decisions with the API @mfulton26 |
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.
-
|
Seems like the The Vite Env API docs don't mention assets, so I'm not sure whether something is supposed to change in that regard. (Very excited and looking forward to the Vite Env API 👀) |
Beta Was this translation helpful? Give feedback.
-
|
hi! I'm experimenting with the Vite Env API in @lazarv/react-server and while I had some issues about using different root for envs, I had much more benefit from using the Env API vs using multiple instances of Vite servers. My feedback on Env API:
All-in-all, even in it's current state, Env API is the way to go, I'll continue to enhance my configuration and keep experimenting with it. Nice work! |
Beta Was this translation helpful? Give feedback.
-
Can you give more information on what the problem is? |
Beta Was this translation helpful? Give feedback.
-
|
I had to do the following patch on the transport, as I experienced issues because of how React resolution should work with the "react-server" loader condition and I had to externalize these React modules in the worker thread this way as the Vite module resolution on the main thread was wrong. Might be some wrong setup on my side, but it's fairly complex to support 3 envs using 2 different React versions while I want to resolve all React imports to the one used by the framework. const remoteTransport = new RemoteRunnerTransport({
send: (data) => {
parentPort.postMessage({ type: "import", data });
},
onMessage: (listener) =>
parentPort.on("message", (payload) => {
if (payload.type === "import") {
listener(payload.data);
}
}),
timeout: 5000,
});
remoteTransport.fetchModule = (id, importer) => {
if (["react", "react/jsx-dev-runtime", "react-dom/client"].includes(id)) {
return { externalize: id };
}
return remoteTransport.resolve("fetchModule", id, importer);
}; |
Beta Was this translation helpful? Give feedback.
-
|
Regarding
I create a PR #17394, but I have issues with the tests, if anyone interested to take a look, I would really appreciate help on that one, thanks! |
Beta Was this translation helpful? Give feedback.
-
|
I'm interested what developer experience the Environment API can unlock, it seems like this could be used to provide HMR with Cloudflare wrangler/workerd ? That is something I've wanted when using CF workers to build SPAs. cc/ @IgorMinar |
Beta Was this translation helpful? Give feedback.
-
|
The Environments API doc claims there are no breaking changes from v5.
However, this doesn't appear to be true. It appears the runtime API has been removed and replaced by the import {
createServer,
- createViteRuntime
+ createServerModuleRunner
} from "vite";
const server = await createViteServer();
- const runtime = await createViteRuntime(server);
+ const runner = createServerModuleRunner(server.environments.ssr);
- const foo = await runtime.executeUrl<Foo>("./Foo.ts");
+ const foo = await runner.import<Foo>("./Foo.ts"); |
Beta Was this translation helpful? Give feedback.
-
|
Although this will require some folks that were experimenting with the Runtime API released in 5.1 (in particular, Hydrogen is using the feature), this isn't a breaking change because it was released as experimental. Even more experimental than other times, with a big warning in the docs that we were going to change it and we were only releasing it to help the community explore. |
Beta Was this translation helpful? Give feedback.
-
|
Vite Runtime API was never stable, it's not subject to semver: https://vitejs.dev/guide/api-vite-runtime.html#vite-runtime-api
|
Beta Was this translation helpful? Give feedback.
-
|
Ah ok. It might be good to reassert that in the Environments API docs. That the runtime API will be removed and replaced by the new API. |
Beta Was this translation helpful? Give feedback.
-
|
Will this API enable the use of the server during build? I have a vite plugin where I need to import |
Beta Was this translation helpful? Give feedback.
-
|
Module Runners are dev only. During build time, you aren't running code, only generating the bundle. |
Beta Was this translation helpful? Give feedback.
-
|
I'm trying out the runner feature, I'm trying to achieve something like vite-node (without creating the actual CLI). I want to run a TS script in watch mode and also have HMR, but I can't figure out the HMR part. I never learned how HMR works internally, I only learned how to consume it, so I didn't know what to put in the vite/packages/vite/src/node/server/hmr.ts Line 904 in d7f46e9 so I tried to use that, but even though I didn't have
|
Beta Was this translation helpful? Give feedback.
-
This is not true.
Seems like we didn't expose import { createServer, createNodeDevEnvironment, createServerHotChannel, createServerModuleRunner } from 'vite'
const server = await createServer({
environments: {
node: {
dev: {
create(name, config) {
return createNodeDevEnvironment(name, config, {
hot: createServerHotChannel(),
})
}
}
}
}
})
const runner = createServerModuleRunner(server.environments.node)On the other hand, I don't understand why you need to create a custom environment instead of just passing down the default - const runner = createServerModuleRunner(server.environments.node)
+ const runner = createServerModuleRunner(server.environments.ssr) |
Beta Was this translation helpful? Give feedback.
-
Unintentional, probably because the what I'm importing also has "node" in it. Thanks for pointing out the oversight.
How do I use it, though? Which part of the |
Beta Was this translation helpful? Give feedback.
-
Replace This is a bug, I will look into it. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, it works! Thank you very much ❤️ |
Beta Was this translation helpful? Give feedback.
-
|
I noticed that if I don't configure I keep learning that Vite will do a deep merge with the defaults, and that I don't have to configure everything. |
Beta Was this translation helpful? Give feedback.
-
|
Currently runners seem to be intended to be used for finite scripts, but in my case I'm using them for a long-running process because my Express code is written in TypeScript, so I'm running the code that starts the Express server with a module runner. This is working pretty ok as hinted in #16358 (comment), but whenever I change the Vite config the runner doesn't restart, I have to do it manually. I didn't really expect this to work, but I'm wondering what the recommended workflow here is 👀 I tried building a development-only plugin that turns on middleware mode and adds Vite's middleware to the Express server in
|
Beta Was this translation helpful? Give feedback.
-
|
This is a great example that fixed one of my main problems. Instead of importing outside the handler I should be importing inside the handler, that was the reason why changes to my SSR source code were having no effect. Instead of {
configureServer(server) {
const runner = createServerModuleRunner(server.environments.ssr);
const handler = async (req, res, next) => {
try {
const mod = await runner.import('/src/server/server.ts');
mod.default(req, res, next);
} catch (err) {
next(err);
}
};
return () => {
server.middlewares.use(handler);
};
},
}What I'd like to achieve now is to catch hot updates of any modules that start with I've been trying things out with the new {
hotUpdate({ file }) {
if (this.environment.name === 'client') {
if (file.includes('/src/server')) {
this.environment.hot.send({ type: 'full-reload' });
return []
}
}
},
}This is a simplified example, the real example was going through the Is there a recommended approach? |
Beta Was this translation helpful? Give feedback.
-
Probably what's missing is that you'll need to watch change in Astro (also other frameworks) plans to do something similar in Vite 6 and this might help https://github.com/withastro/astro/pull/11979/files#diff-c13c74ccffcd018429b8800d30e3be92e31d4a7a8595a1fee0e300e8b1ae8591 |
Beta Was this translation helpful? Give feedback.
-
|
That's clever, I didn't think to mix & match like that! I guess that's in part why that hook exists 😄 But I'm facing continuous data loss as I'm changing files, and I managed to come up with a repro based on the Data fetching is contrived to reflect how my app is fetching data, but it's still small. If you edit any of the SSR files the data value from the singleton will be gone and my app will have to refetch it. Initially I thought that I should be using Or should I be using something like |
Beta Was this translation helpful? Give feedback.
-
|
The thing is that I'd like to revalidate that data fetching in case I change certain files (in this case pretty much just Anyway I just wanted to know which tool should I be using to solve my problem. public static get singleton() {
if (import.meta.hot) {
import.meta.hot.data.singleton ??= new Data();
Data.#singleton = import.meta.hot.data.singleton;
} else {
Data.#singleton ??= new Data();
}
return Data.#singleton;
} |
Beta Was this translation helpful? Give feedback.
-
I would imagine using |
Beta Was this translation helpful? Give feedback.
-
|
I apologize for my ignorance, I'm new to Vite, and I'm hoping to build a plugin library that essentially provides you an API router. I'd like people to be able to use the plugin with their choice of runtime in their project - node, bun, deno, etc (including runtimes on the edge). Routes are declared with directories and route.js files (or .ts). I have a POC working with the Bun runtime, using a Bun plugin; but it seems to have some limitations that Vite's Environment API might be able to address. I've read the basic Rollup plugin docs, gone through the Environment API docs a couple of times, but I'm not understanding if the new API is a good use-case for me to try. Everything is a bit overwhelming for a newbie - at least for me. I figured I could create a bun environment, which has some type of module runner; but, in the flow graphic at the top of the docs, I'm not understanding how the runtime (workerd in the graphic) is tied to the module runner and Vite dev server. I assumed I'd be able to somehow determine that a dev is wanting to use the Bun runtime, then use Bun.serve to serve their routes during dev; then, of course, bundle everything at buildtime. Any insights? |
Beta Was this translation helpful? Give feedback.
-
|
I noticed that we have a same problem with #12734 if a different server (e.g. miniflare) is used in DevEnvironment. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe it's easier to revert #12379 and apply a different fix for #12375. |
Beta Was this translation helpful? Give feedback.
-
|
I see the issue now. It was working when miniflare assigns random port, but it crashed when fixed the port: 6:26:36 PM [vite] server restarted.
6:26:38 PM [vite] vite.config.ts changed, restarting server...
workerd/util/symbolizer.c++:101: warning: Not symbolizing stack traces because $LLVM_SYMBOLIZER is not set. To symbolize stack traces, set $LLVM_SYMBOLIZER to the location of the llvm-symbolizer binary. When running tests under bazel, use `--test_env=LLVM_SYMBOLIZER=<path>`.
*** Fatal uncaught kj::Exception: kj/async-io-unix.c++:945: failed: ::bind(sockfd, &addr.generic, addrlen): Address already in use; toString() = 127.0.0.1:12345
|
Beta Was this translation helpful? Give feedback.
-
|
Made an issue here: #18264 |
Beta Was this translation helpful? Give feedback.
-
|
I seem to have run into an incompatibility with the module runner and the client bundler, they're processing the https://stackblitz.com/edit/vitejs-vite-3bjmc7?file=index.html In the browser console you can see the error that Is there something specific about this module that's causing this incompatibility? |
Beta Was this translation helpful? Give feedback.
-
|
Probably this is an issue on I would assume Btw, this is not technically an issue with environment api specifically (should be reproducible on old |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot, this is indeed a problem with the package, not the API, I totally spaced out on the As a quick fix I'm using only named exports and forced You guys are super helpful, I really appreciate it ❤️ |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I noticed one "quirk": |
Beta Was this translation helpful? Give feedback.
-
|
It looks like |
Beta Was this translation helpful? Give feedback.
-
|
Makes sense 👌 |
Beta Was this translation helpful? Give feedback.
-
|
Unrelated feedback to the above. I'm confused by the intention behind {
build: {
createEnvironment(name, config) {
// this doesn't work 😕 at least not in "vite build --app"
return new BuildEnvironment(name, config, { options: config.environments[name] });
},
},
environments: {
ssr: {
build: {
target: 'node20',
},
},
},
builder: {
sharedConfigBuild: true,
},
}Nor does varying config passed to |
Beta Was this translation helpful? Give feedback.
-
|
That is a bug. On a related note, we discussed with Bjorn and he was very interested in not allowing |
Beta Was this translation helpful? Give feedback.
-
|
Why only |
Beta Was this translation helpful? Give feedback.
-
|
Having environment config defaults at root is important to keep Vite as simple as it is today to configure for SPAs. It is a hard sell if the simplest config becomes: export default defineConfig({
environments: {
client: {
build: {
minify: false
}
}
}
})For SPAs, this will also force us to introduce environments right away to users. There are some team members that think that we should keep environments as an advance feature too. I think once you introduce One thing that we could do in the future is to remove |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I understand, this has to be handled very gradually. In your example top-level And the top-level |
Beta Was this translation helpful? Give feedback.
-
|
Yes, we have |
Beta Was this translation helpful? Give feedback.
-
|
I noticed that Is this behavior deliberate? I realize that the API could in that case be tricky because what would it mean if |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Ok, |
Beta Was this translation helpful? Give feedback.
-
|
I have a plugin that is working, but I can't figure out how to get HMR fully working when I change a route file. Anyone know how I can resolve this? Here is part of my plugin. During my attempt to work around this, I'm declaring async configureServer(server) {
console.log('########## CONFIGURING SERVER ##########')
//const runner = createServerModuleRunner(server.environments[validated_config.environment])
runner = createServerModuleRunner(server.environments.ssr)
await createManifest(runner, validated_config, true)
api = await runner.import(path.join(cwd, 'index.ts'))
server.middlewares.use(async (req, res) => {
console.log('running vite middlewares')
const base = `${server.config.server.https ? 'https' : 'http'}://${req.headers[':authority'] || req.headers.host}`
const request = await getRequest(base, req)
const response = await api['default'].fetch(request)
setResponse(res, response)
})
},
async hotUpdate(context) {
console.log('changed file', context.file)
/* Ensure we only try to import if a route file has changed. */
if (context.file.includes('route.ts')) {
console.log('import route file')
await runner.import(context.file)
console.log('done importing route file')
}
/* Import server entry file. */
api = await runner.import(path.join(cwd, 'index.ts'))
}I experimented with When changing the entry point index.ts file, and saving changes, here is what happens - entry point changes are reflected at runtime.
When changing a route file, and saving changes, here is what happens - route file changes are not reflected at runtime.
|
Beta Was this translation helpful? Give feedback.
-
|
async hotUpdate(context) {
if (context.file.includes('route.ts')) {
await createManifest(runner, validated_config, true) /* Custom function that handles newly-created route files. */
this.environment.hot.send({ type: 'full-reload' }) /* Handles updated route files. */
}
api = await runner.import(path.join(cwd, 'index.ts')) /* Needed for all changed files, but alone covers the server entry point. */
} |
Beta Was this translation helpful? Give feedback.
-
|
It's possible that you don't need the api = await runner.import(path.join(cwd, 'index.ts'))inside your Check out the example in Vite's playground: vite/playground/environment-react-ssr/vite.config.ts Lines 74 to 75 in 1fe949d |
Beta Was this translation helpful? Give feedback.
-
|
@silvenon you're right! I thought I had tried that already and it threw, but it's working. Thanks!! (Still need |
Beta Was this translation helpful? Give feedback.
-
|
Here is what async hotUpdate(context) {
if (context.type === 'create' && context.file.includes('route.ts'))
await createManifest(runner, validated_config, true)
} |
Beta Was this translation helpful? Give feedback.
-
|
Great! Glad you got it working! I thought importing on every request would be costly, but apparently the module runner is very efficient 💨 |
Beta Was this translation helpful? Give feedback.
-
|
So, am I supposed to be able to literally use a runtime (Deno, Bun, etc) for the dev server, or do you always have to use Vite's Connect dev server - even with the Environment API? I've just barely been able to glue something together, where my plugin is importing the developer's server module, and then I'm manipulating Vite dev server's Connect.IncomingMessage Beside that, I'm still trying to wrap my head around when you'd wire up a custom environment. I apologize for my ignorance. |
Beta Was this translation helpful? Give feedback.
-
|
The new environment API docs answered my question; which seems to be: "you still have to go through the Vite dev server, even if another runtime is ultimately handling the request/response" |
Beta Was this translation helpful? Give feedback.
-
|
Vite's dev server will be running in another runtime anyway, no? It won't be as efficient as writing a Vite dev server just for Bun, but AFAIK it's not nothing. Also, I think it's safer to attach your own middleware after Vite attaches its own, so in the function returned by |
Beta Was this translation helpful? Give feedback.
-
|
What advantages are there to allowing vite to run its middleware before my own? And how would I configure it to work as such? |
Beta Was this translation helpful? Give feedback.
-
|
My thinking was that it would find stuff like assets sooner. Currently by running your app before Vite's own middleware your app is being run for absolutely every app request. But by plugging in your app afterwards your app might not need to run at all for many requests, because they will have been handled by Vite's own middleware. Here's how you would set that up: configureServer(server) {
runner = server.environments.ssr.runner
const handler = async (req, res) => {
const web_server = await runner.import(path.join(cwd, entrypoint))
const request = await convertIncomingMessageToRequest(req)
const response = await web_server.default.fetch(request)
convertResponseToResAndReturn(res, response)
}
return () => {
server.middlewares.use(handler)
}
},The only difference is that the handler is plugged in in the returned function rather than immediately. Vite calls that function once it adds its own middleware. |
Beta Was this translation helpful? Give feedback.
-
|
Gotcha, thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Regarding |
Beta Was this translation helpful? Give feedback.
-
|
I am open to renaming if you think it reflects the naming convention better. I am not sure about |
Beta Was this translation helpful? Give feedback.
-
We decided to release the Environment API branch as
[email protected](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
[email protected]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
ViteBuilderthat lets frameworks orchestrate all the environment builds they need to get a singlevite buildcommand 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