IssueRaiser

Consider treeshaking module for serving files in dev mode

### Clear and concise description of the problem Hello! Lately as our codebase has grown bigger and bigger over the last months we've been experiencing slow page reloading using Vite. That is not surprising given that our module size went off the chart, but it really is becoming a real pain point for us. I hear that we are not alone in this case, reading through some related issues: https://github.com/vitejs/vite/discussions/8232 and I totally agree with what @patak-dev says here: https://github.com/vitejs/vite/issues/7608#issuecomment-1087877492 The thing is, HMR has some reliability issues in our large codebase (where sometimes patching generates some issues) and these issues are very hard to debug, and creating a minimal reproduction is a huge amount of energy (for potentially no results) I failed to follow up on that ticket as well: https://github.com/vitejs/vite/issues/3719 --------- With all that said, we are guilty of doing something that really does not help: we often import shared code with an index file because it is handy: ```ts // /shared/index.ts export { a } from './a' export { b } from './b' export { c } from './c' ``` ```ts // Component.vue import { a, b } from '/shared' // instead of import a from '/shared/a' import b from '/shared/b' ``` Of course, I already hear people say: 'Duh! just don't do this and import every single module individually you lazy dumbass' I would answer: easier said than done when your codebase is a big monorepo and you share

Posted by AlexandreBonaventure on May 19, 2022, 1:51 PM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments

ux (EdTech)

Consider treeshaking module for serving files in dev mode

AlexandreBonaventureMay 19, 2022, 1:51 PM

### Clear and concise description of the problem Hello! Lately as our codebase has grown bigger and bigger over the last months we've been experiencing slow page reloading using Vite. That is not surprising given that our module size went off the chart, but it really is becoming a real pain point for us. I hear that we are not alone in this case, reading through some related issues: https://github.com/vitejs/vite/discussions/8232 and I totally agree with what @patak-dev says here: https://github.com/vitejs/vite/issues/7608#issuecomment-1087877492 The thing is, HMR has some reliability issues in our large codebase (where sometimes patching generates some issues) and these issues are very hard to debug, and creating a minimal reproduction is a huge amount of energy (for potentially no results) I failed to follow up on that ticket as well: https://github.com/vitejs/vite/issues/3719 --------- With all that said, we are guilty of doing something that really does not help: we often import shared code with an index file because it is handy: ```ts // /shared/index.ts export { a } from './a' export { b } from './b' export { c } from './c' ``` ```ts // Component.vue import { a, b } from '/shared' // instead of import a from '/shared/a' import b from '/shared/b' ``` Of course, I already hear people say: 'Duh! just don't do this and import every single module individually you lazy dumbass' I would answer: easier said than done when your codebase is a big monorepo and you share

Comments (0)

No comments yet. Start the discussion.

Comment on this issue