feat(core): Replace Webpack with Rspack - siteConfig.future.experimental_faster.rspackBundler
#10402
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
⚡️ Lighthouse report for the deploy preview of this PR
|
✅ [V2]
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Size Change: +63.4 kB (+0.57%) Total Size: 11.2 MB
ℹ️ View Unchanged
|
slorber
added
the
Argos
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
hardfist
reviewed
Aug 16, 2024
This was referenced Aug 19, 2024
|
Are you considering runtime sizes as well before proceeding with this migration ? It seems that the bundler community is solely focused on who's faster (farmfe/rspack/turbopack etc), while almost no attention is being paid to the actual runtime javascript sizes whatsoever. Even rspack's documentation is very vague on what it does exactly to reduce the code size compared to webpack 5. I'm posting the measured network size (Chrome devtools Network tab) for the preview link vs the main branch. I do realize that this PR is behind the main branch, so the numbers might vary when the PR is updated. But here is what I see: Rspack PoC (netlify URL)JS: 9 requests, 1.0 MB compressed, 2.7 MB uncompressed Webpack 5 (docusarus.io)JS: 10 requests, 981 KB compressed, 2.0 MB uncompressed If we assume that the "base" is the same, there is a ~716 KB (minified) diff between webpack and rspack. Feel free to adjust the numbers after a rebase, but this is definitely concerning. I appreciate the build time perf boost. It is quite important. But we must not forget that there is a lot more to performance than pure blind speed. I cannot see any concrete numbers or benchmarks around "runtime" sizes either. Most comparisons are based on webpack-bundle-analyzer, which is incorrect since the |
|
@tmpaul yes we obviously consider this, we even have a bot to warn us: And bundler authors as well This is why this PR is a draft POC, it's not ready to merge. We are already aware of that code splitting problem. Most likely we'll provide an experimental feature flag to turn Rspack on. |
slorber
changed the title
siteConfig.future.experimental_faster.rspackBundler
|
Rspack support is now good enough to merge 🎉 Note that the Rspack bundles are still a bit larger than Webpack:
This is actively being worked on and will be fixed later as part of: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Docusaurus Faster
This PR is part of the Docusaurus Faster project aiming at reducing production build times
Motivation
Rspack is mostly retro-compatible with Webpack and the most suitable choice for Docusaurus in the short term (see also #4765 (comment))
This PR adds opt-in experimental support for replacing Webpack with Rspack.
Note it's not 100% compatible. There are some subtle differences to consider.
Plugins authors implementing
configureWebpack()might need to adjust their code to add Rspack support: see #10572Extra notes:
output.environmentand the JS is slightly larger (WIP, see Align module exports with webpack web-infra-dev/rspack#5316)Benchmark
This is an approximate local benchmark run locally on our Docusaurus website. It is not necessarily representative of the performance gains you'll obtain on your own site.
We are measuring with
faster: trueVSfaster: false(not justrspackBundler: truewhich depends on some other options to be enabled).Benchmark - Cold builds
As expected, Rspack is much faster on cold builds. In our case, more than 3x faster.
Benchmark - Warm re-builds
As expected, Rpack is slightly slower on warm re-builds.
This is likely temporary until they implement support for Webpack persistent caching.
Note: despite slightly slower rebuilds, we believe it's still worth it to turn Rspack on to future-proof your site against Rspack.
This benchmark doesn't take into account any site edit that might invalidate the persistent cache. We didn't modify any JSX/MDX file before rebuilding, which happens in practice.
Also, faster Webpack rebuilds require additional CI setup to save/restore the persistent cache that we never documented properly (outside of mentioning it on issues such as #4765) so it's likely most users do not leverage it anyway.
Test Plan
CI + unit tests
Test links
https://deploy-preview-10402--docusaurus-2.netlify.app/
Related issues/PRs
#4765