Replies: 4 comments 17 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 the vite team is actively working on a faster compiler (in Rust) right now, and the idea is that once that's done you'll have the option to switch between unbundled and bundled modes in development. Since the bottleneck is the number of files, that should eliminate this problem. That said, I also know they're planning on rolling out the compiler first for prod builds only, and it's still not at that point. So, not helpful right now but maybe soon-ish. If our perf problems were a bit worse (reloads take 2-3s right now) I would consider doing my own prebundling in dev with esbuild -- specifically for my dependencies. But that's a fair bit of work and not worth it for us given where we are right now. If you go that direction, though, I'd be interested to hear about it! |
Beta Was this translation helpful? Give feedback.
-
|
@davidwallacejackson We have worse reloads than that so we have to do something here. Regarding prebundling, one of the comments above says it breaks HMR on file changes which doesn't seem ideal. It seems like the best option here is to improve our codebase for better use of dynamic imports and lazy loading of components. Just don't have a sense of how easy that is to do and what the gains will be. |
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.
-
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