Replies: 6 comments 24 replies
-
|
Available using: https://vitejs.dev/config/#optimizedeps-include |
Beta Was this translation helpful? Give feedback.
-
|
It's clear how you can use dependency pre-bundling for external modules, but it's not clear how to do it for the application itself. Our app has a few thousand files, these have to load over the network for every refresh. Leading to a worse developer experience than we had with Webpack for the initial load. |
Beta Was this translation helpful? Give feedback.
-
|
Does anybody managed to figure it out? |
Beta Was this translation helpful? Give feedback.
-
|
No. Have some problems |
Beta Was this translation helpful? Give feedback.
-
|
It's possible to pre-bundle internal parts of the application by using alias to reference what should be pre-bundled |
Beta Was this translation helpful? Give feedback.
-
|
prebundling does not react to changes to the files however so that is a non-starter. |
Beta Was this translation helpful? Give feedback.
-
|
We already have 1600 files and it's getting a pain to worth with the project. Build time is extremely fast, yet loading in the browser is very slow. We might even pass 3K files based on our expansion plans. We would also welcome this feature very much. |
Beta Was this translation helpful? Give feedback.
-
|
Would you send here a cpuprofile for warm start? Use It would be good to go through https://vitejs.dev/guide/performance and see what you could apply for your use case. Extensions have a huge effect for example when there are a lot of modules https://x.com/patak_dev/status/1745427465617433005?s=20 |
Beta Was this translation helpful? Give feedback.
-
|
How is the cpu profile going to help debug this ? |
Beta Was this translation helpful? Give feedback.
-
|
I want to chime in that we are facing the same problem. On dev the initial page load fetches ~3.6K files... This is an insane amount. |
Beta Was this translation helpful? Give feedback.
-
|
For instance we use css modules and the browser ends up loading ~750 css files alone |
Beta Was this translation helpful? Give feedback.
-
|
For what it's worth, switching to Vite was still a net benefit for us even with tons of modules. Faster productions builds, better hot reloading, and quicker initial startups for dev outweighed the reload cost. Still want this solved, of course, but we're much happier than we were with webpack. |
Beta Was this translation helpful? Give feedback.
-
|
@davidwallacejackson I cannot agree with you.
The HMR works fine on small projects like
Oh man... How many modules do you have? The reason - browser starts really well, but the application starts after 1 minutes with many page reloads. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure how many modules we have total, but about 2000 load synchronously on startup. The first page load in browser after starting up generally runs about 30-40s, after which they're a second or two. Not great, obviously but with webpack we were waiting minutes for the dev server to even start. Maybe it's better these days? Re: hot reloading: my experience has been that the HMR is astonishingly fast on large projects... if you're following the sometimes arcane best practices of React Fast Refresh (no clue about other frameworks). It's tricky to do that, though -- there really needs to be a linter to help remind developers to not mix component and non component exports, for example. Import cycles are also easy to create in large projects and completely ruin hot reloading for every module they encompass. I think we also got faster prod builds, though it's been so long since the switch I don't have apples to apples comparisons anymore, and our build times have now crept up over 12 minutes as the app has grown. I personally care a lot about prod build speed because we use our prod builds in our integration tests, so it has a huge impact on CI runtimes. Again, none of this is great. If I were starting fresh, I think I'd at least give Next a shot and see how I like it (we're purely a React shop) but it seems like there aren't currently any options that combine speed and flexibility to the extent we'd like, and we just have to make compromises. I am really, really hoping that Rolldown makes a difference here, though I don't know what the timeline is on that. |
Beta Was this translation helpful? Give feedback.
-
|
Just my 2 cents, I just migrated away from NextJs in favor of vite on one of our project (not a very big project at all). |
Beta Was this translation helpful? Give feedback.
-
|
Anyone make any progress on this or have idea how to improve it? This is a huge pain point for devs of large projects. |
Beta Was this translation helpful? Give feedback.
-
|
@jdavis we had same problem with with moving from webpack 5 into Vite. We decided that until rolldown (that’s the name of new project Vite project) will become and will be confirmed that bundled development environments are stable - we cannot use Vite. The performance and DX was so bad.. If you are looking for some DX improvements we highly recommend project called Rspack (https://rspack.dev). We moved from webpack 5 into repack. The numbers:
Rspack is also using Rust. Worth. Trust me. |
Beta Was this translation helpful? Give feedback.
-
|
@OskarLebuda Unfortunately moving to Rspack isn't in the cards and I'm still looking for solutions. |
Beta Was this translation helpful? Give feedback.
-
|
@jdavis you can also try this plugin: https://github.com/antfu/vite-plugin-prebundle |
Beta Was this translation helpful? Give feedback.
-
|
We looked at migrating to Vite from Webpack but ran into this issue so are now using esbuild. It is faster than Webpack and doesn't have this issue with Vite. We'll look at trying Vite again once they support bundled modules in dev. |
Beta Was this translation helpful? Give feedback.
-
|
I just noticed another "Rust loving"/"Vite compatible" tool in the town: farm-fe/farm. They seem to address the issue with gazillion files being loaded during dev mode. |
Beta Was this translation helpful? Give feedback.
-
|
I really can't understand why vite can't check every file from its cache at startup to see if it's still valid, and send them all in a single payload in dev mode regardless of if they're going to be used. Cost would be pretty minimal. Then vite runtime in browser would use the cache instead of a request first if possible until first cache invalidation. what https://github.com/antfu/vite-plugin-prebundle does feels so logical; hope it would be finished/working in more cases. What is the hidden reason this is not yet the default; it kinda baffles me compared to how popular / widespread it is. I know it's probably an overly optimistic estimation, but it really feels like a 2 day poc from one core vite contributor IMO. (not really a rant, but a personal comment I feel may be useful to hear): Vite is awesome, I love it... BUT: the sad part is that every year, I look for a solution to this very issue, and come to the same sad conclusion that vite is either not that "smart" or not properly maintained. And people around me too now have the mentality of "let's just wait for some better tool". Slow desillusion for such a cool project. If anyone want to attempt to fix that user-land, I guess it is probably doable with some web worker local to your projects, intercepting requests, returning some local cached version "synchronously", while still sending the request to check if things changed to invalidate things. may be tricky, but feels worth trying at this point. and thanks for the cool project anyway :) |
Beta Was this translation helpful? Give feedback.
-
|
farm document it's approach here: and in more details here: https://github.com/farm-fe/rfcs/blob/main/rfcs/003-partial-bundling/rfc.md |
Beta Was this translation helpful? Give feedback.
-
|
their approaches is indeed a bit more advanced than what I would consider doable in 2 days 😅 but still; sounds like they do way more than the bare minimum viable implementation that would still benefit all big projects using vite |
Beta Was this translation helpful? Give feedback.
-
Because of the performance of this.
Probably nobody thought about it at the beginning of the project. Prebundle type should be available soon (milestone 4 of Rolldown). In out big project we decided to move into rspack and wait for rolldown full bundled mode. |
Beta Was this translation helpful? Give feedback.
-
|
Is there any estimate time of release for Rolldown (+ vite integration of rolldown)? |
Beta Was this translation helpful? Give feedback.
-
Currently, vite doesn't perform well with large projects with a lot of modules (1000+) on
devmode. The bottleneck is on the browser side:The bundled app is less than 50KB but it requires a lot of dependencies (I'll provide a sample repo soon). So currently vitejs cannot be used for large or very fine grained applications 😢
We could probably fix it by bundling and caching on the fly some of the modules. It's not an simple task, but this could help a lot to scale vitejs.
Other ideas or solutions ?
Beta Was this translation helpful? Give feedback.
All reactions