-
-
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
perf: lazy load rollup during dev #15621
Conversation
Run & review this pull request in StackBlitz Codeflow. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Extracted the |
I'm not really oppose to this, but it's kinda unfortunate that we can't use the exported version now. Should we reach to Rollup if they could export it as a subpath? (though feels a bit redundant, i guess it would be nice if the utils are placed under |
Do you mean that rollup should expose a small |
Yeah I think we can figure out the |
I extracted the esbuild changes as a draft to This PR only avoids statically loading rollup before the server starts now. I need to run proper benchmarks with the other extracted PRs so we can discuss them further 👍🏼 |
Description
Edit:
This PR now only avoids statically importing rollup before the dev server starts.
Other parts have been extracted to:
Context
We merged some PRs that moved rollup from being lazily loaded during dev (see for example a here for a properly use of rollup) to being statically imported and blocking the server init.
This PR reworks the changes done in the following PRs so rollup is lazily loaded again:
With this PR, the dev server is starting ~15% faster on my M1, seeing sub 100ms now.
For #14833, if we want to continue to expose the sync
parseAst
from rollup, we need to do it by also exporting aninitRollupParseAst
function that should be called before it. This is breaking but I don't think there should be much usage for it yet. I can break the PR if needed but it would be good if we could merge it for Vite 5.1 and not have to wait for Vite 6cc @sapphi-red, @sheremet-va, @bluwy as we were all involved in reviewing the PRs above
What is the purpose of this pull request?