-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace $ vite build && vite build --ssr
with $ vite build
+ enable plugins to add build step
#5936
Comments
I'm going to put some time on this one. See if I can tackle it down! |
@aleclarson Thoughts on this? Could be relevant for https://github.com/alloc/viteflare. |
@brillout would you extend the API you are proposing? In your config example, |
I'm glad this is getting attention. There is a big need for shared deploy adapters & plugins that the whole Vite ecosystem can use. Instead of having vps, SvelteKit and Astro re-invent the wheel. (@cyco130 is experimenting on something quite exciting in that space, and @magne4000 is working on vite-plugin-vercel which supports Vercel's ISR platform.) I think the Being able to append tasks to The neat thing here is that we can re-use Vite's I'd suggest to experiment with the As for defining new commands, I don't see much complications here. One thing though: other than |
Just FYI, this acronym is a bit confusing / overloaded because we also use it for
It's gotten a bit more complicated on our side. SvelteKit has introduced server-side route splitting. This means that some of SvelteKit's adapters now have to know how to map SvelteKit routes to the routing functionality of each hosting platform. As a result, it'd be hard to share given the need for SvelteKit-specific logic. Perhaps there could be general adapters and each framework could provide their own route-splitting functionality, but it's gotten more complicated at least. Still, there are adapters that don't do route splitting like |
I've talked a bit about Saus recently (for those who missed it: link), which could provide routing primitives and route-based code splitting if Vite decides not to go that route (no pun intended). The vision is that full-stack frameworks share a lot more in common than they're currently taking advantage of, so there should be a layer like Saus that helps with that. Such a layer would be a lot better of a candidate for a deployment adapter API that every Vite-based framework could use (indirectly through plugins). Finally, there was a Twitter thread all about this direction just recently (link). |
Here's the work I've done that @brillout refers to: https://github.com/cyco130/vavite (in particular the |
I agree that given the current parallel explorations happening it may be too soon to formalize things in Vite core. @brillout your idea of a new |
Is the idea that this command would execute a |
My idea was to extend it later with |
Do we really need a DAG? I do agree that a real task runner needs to be a DAG, but we only have a handful of tasks. Concretely,
Also note that pre-rendering needs to await Rollup bundling; we cannot parallelize these two. For only three steps, I don't think we need a DAG. But maybe there are more steps I'm not foreseeing. I propose we start without a DAG at first and see how it goes.
Good point. I'm 👍 for replacing The world is ripe for deploy adapters. If Vite delivers on this, that's big. Guillermo Rauch (Vercel CEO) is supportive, and Cloudflare Workers, I'm confident, will shortly follow, and with it all other deploy providers.
That's how I felt at first as well, but I ended up liking it. Because it fits well with the current Rollup plugin architecture. it's simple and it works. We can use the Anyways, in the meantime, let's see how things go with the
Yes.
Only one plugin is allowed to define the Also CC'ing @Aslemammad who's working on |
As for the off-topic discussions, see: |
SvelteKit has been updated so that all building occurs within a Vite plugin. Calling |
Same for vite-plugin-ssr 0.4. I believe Rakkas also does this (although it uses another hook IIRC). Let's see how this pans out. |
I just released vite-plugin-ssr 0.4 that includes the Implementation: https://github.com/brillout/vite-plugin-ssr/blob/514843f92af77324d5038169ea2f45bfe7db7816/vite-plugin-ssr/node/plugin/plugins/autoFullBuild.ts. Let's see how it works out. |
SvelteKit has five build steps that must be run sequentially as each depends on the output of the step before it. One way to support this would be if Vite supported an array of configs just as Rollup does. Our builds could potentially look something like:
An alternative solution may be to have Rollup change Right now, we're kicking off the server, prerender, and service worker from We've reached the limits of this approach. We're trying to let people optionally switch out our service worker implementation for Allowing these to be separate builds or have more build steps would also allow us to refactor more of this to occur in shareable Vite plugins. E.g. as @brillout mentioned above, if adapters were Vite plugins then they could be shared across the ecosystem. I've seen others running multiple bundlings as well. E.g. in addition to the folks that have already been mentioned in this thread above, Trade-offs between multiple builds in config vs chaining builds with a hook:
|
@benmccann Is there actually a need for multiple builds in |
@aleclarson we need to run multiple builds, but they don't have to be defined via |
I agree this is something limiting the ecosystem to grow and innovate. And we should figure out a better way to improve it. While changing it to complete sequential will hurt the performance and probably be a significant breaking change to the ecosystem. I'm thinking maybe we could have it per-plugin level control of whether those plugins should be executed parallel or sequential. We might need to figure out a good design of how we could express it by extending the current API.
In general, I am against doing this. Even if it can be possible, I would personally think it's a bit anti-pattern. Vite as a front-end tool is mainly for building the client app, given its pretty low-level, meta frameworks calls I think multiple builds should be handled by upper-level frameworks to call Vite programmatically (multiple times at different timing), just like how we do it in many frameworks now. If we really want to rescue the CLI from Vite, I guess we could introduce a separate command like |
I'm not sure if |
RFC by antfu: https://hackmd.io/WgkOsRmpT0e5ACJHc0Dh6Q |
RFC here: https://github.com/vitejs/vite/discussions/9442 (solving the limitation of |
RFC summary: https://github.com/vitejs/vite/discussions/9442#discussioncomment-3303445. New discussion for #9496 - Should |
Closed as #9496 (comment) |
Clear and concise description of the problem
We want to build deploy plugins, e.g.
vite-plugin-cloudflare-workers
,vite-plugin-vercel
, andvite-plugin-deno-deploy
.Currently, the user would need to:
Suggested solution
Additional context
There is an increasingly number of deploy environments.
This ticket enables deploy plugins which in turn enables deeper collaboration between SSR frameworks.
Eventually it is the deploy providers who will maintain these plugins. (Like how Cloudflare Workers took over
miniflare
.)Validations
The text was updated successfully, but these errors were encountered: