feat(core): Replace Webpack with Rspack - siteConfig.future.experimental_faster.rspackBundler
#10402
Conversation
⚡️ 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 ↗︎
|
|
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: |
|
@slorber How could I go about adjusting the rspack config when It appears I need to disable this custom webpack plugin to use It looks like rspack has a similar config using the same polyfill, and I'm wondering how I can include this with the Docusaurus rspack config. Here's a link to our repo where I currently have the custom webpack config. I would like to replace this plugin with a custom rspack plugin using the same polyfill. |
|
@JKarlavige the You didn't share why you need to disable your Webpack plugin. If you get an error with the custom plugin, please share the error message. Most likely, this is because of Your node polyfill is compatible with Rspack: https://github.com/Richienb/node-polyfill-webpack-plugin/releases/tag/v3.0.0 But your Docusaurus plugin is not. Here's likely the solution: - const webpack = require('webpack');
const NodePolyfillPlugin = require("node-polyfill-webpack-plugin")
// Adds custom configurations to webpack
module.exports = function customWebpackConfigPlugin() {
return {
name: 'docusaurus-custom-webpack-config-plugin',
- configureWebpack() {
+ configureWebpack(config, isServer, {currentBundler}) {
return {
resolve: {
fallback: {
"fs": false,
"path": require.resolve("path-browserify"),
"http": require.resolve("stream-http"),
"tty": require.resolve("tty-browserify"),
}
},
plugins: [
- new webpack.DefinePlugin({
+ new currentBundler.instance.DefinePlugin({
'process.versions.node': JSON.stringify(
process.versions.node || '0.0.0',
),
}),
new NodePolyfillPlugin({}),
],
module: {
rules: [
{ test: /\.py$/, loader: 'raw-loader' }
]
}
}
}
}
} |
|
@slorber I appreciate the help. Here is the error I receive when starting the dev server, and I receive the same error on builds. I tried replacing And here is the state of the custom webpack plugin after the edits: |
|
@JKarlavige cf the release notes I linked above: https://github.com/Richienb/node-polyfill-webpack-plugin/releases/tag/v3.0.0 This Webpack plugin is only compatible with Rspack starting v3+. You didn't upgrade it, and you are still on v1 (incompatible). Webpack plugins also need to be compatible with Rspack, following similar practices (avoiding static imports from the webpack npm packages). See https://github.com/Richienb/node-polyfill-webpack-plugin/pull/48/files |
|
@slorber Good call, upgrading the polyfill package fixed that specific error. However, I assume upgrading the |
|
I don't know what this problem is but that doesn't really seem related to Docusaurus. Most likely you need to handle the potential breaking changes of the webpack plugin you upgrade. I'd recommend upgrading first in a separate PR. Maybe you just need to add extra polyfills to your config, I don't know |
|
Yeah for sure, it seems like a separate issue with our webpack config, which admittedly I am not the most familiar with. Doesn't appear to be specific to Docusaurus, and i'll keep digging into resolving the current error. Thanks again for your help! |
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