DEV Community: Diwaker Singh

Webpack to Rspack: A Deep Dive Into Our Build Time Breakthrough

Diwaker Singh — Sun, 20 Jul 2025 06:16:43 +0000

1. Why We Migrated

We maintain a large, multi-entrypoint Single Page Application (SPA) with a custom router and integrated micro-frontends via Module Federation. With over 11 independent entry bundles and full CI pipelines, build performance had become a major bottleneck — especially with Webpack.

Our main goal: dramatically reduce build time without touching bundle size or runtime behavior. Rspack promised faster builds with familiar Webpack compatibility, and it delivered — but not without a few surprises.

2. Migration Plan and Scope

We opted for an all-at-once migration rather than phasing. This included:

Replacing Webpack with Rspack in all configs.
Moving from webpack.config.js to an array-based rspack.config.js.
Updating all build/development scripts to use Rspack CLI.
Ensuring all CI/CD pipelines, microfrontends, and chunk-loading logic remained intact.

Rspack supports exporting an array of configs. Here's our rspack.config.js:

module.exports = [
  require('./rspack/agency-admin.config.js'),
  require('./rspack/surveys.config.js'),
  require('./rspack/server.config.js'),
  ...
];

Each config builds independently in parallel — ideal for our multi-app setup.

3. Config Refactor: Before and After

Our configs are modular: each specific app config extends a shared base.config.js and webapp.config.js. Here's how we structured a few key parts.

✅ Example: `agency-admin.config.js` Highlights

output: {
  filename: DEVELOPMENT
    ? 'scripts/engage/[name].js'
    : 'scripts/engage/[name]/[contenthash].js',
  chunkFilename: DEVELOPMENT
    ? 'scripts/engage/[name].chunk.js'
    : 'scripts/engage/[name].chunk/[contenthash].js',
}

Module Federation was preserved using Rspack’s ModuleFederationPluginV1.
Asset stats were written using our custom AssetManifestPlugin.

✅ Server Config (`server.config.js`)

Uses target: 'node'
externals configured with webpack-node-externals
Critical remotes loaded dynamically via module federation

4. Plugin & Loader Compatibility

Most Webpack loaders worked out of the box with minimal rewiring. However:

🛠️ Custom Plugin: `AssetManifestPlugin`

We retained a hand-written plugin that generates a stats manifest JSON:

compiler.hooks.done.tapPromise(pluginName, async (stats) => {
  const statsJson = stats.toJson({ entrypoints: true, chunks: true, ... });
  await writeFile(filepath, JSON.stringify(statsJson, null, 2));
});

No changes were required to make it work with Rspack — a good sign of API stability.

5. Performance Gains

Metric	Webpack	Rspack	Gain
Full Build	1032.47 s	312.92 s	~70% ↓

The improvement was immediate, both locally and on CI (Jenkins). No changes were required in CI jobs — we simply swapped out the CLI in package.json.

6. Gotchas

⚠️ `chunkhash` Collision in S3 Artifacts

We store all built assets in S3 using [chunkhash] filenames.
After the switch to Rspack, a few files generated the same chunkhash as previous Webpack builds — but with incompatible runtime formats.
Because we don't delete old artifacts, our CDN served a Webpack-built file instead of the new one.

✅ Fix:

Switched from:

filename: '[name].[chunkhash].js'

To:

filename: '[name].[contenthash].js'

This made the hashing content-aware and eliminated the risk of mismatched builds.

⚠️ `ContextReplacementPlugin` Shim Removed

During our initial POC, Rspack lacked support for ContextReplacementPlugin, which we relied on in Webpack. We wrote a custom shim to mimic it.

By the time we fully migrated, Rspack had added support, allowing us to delete the shim and simplify the config.

⚠️ Runtime Global Clashes

Rspack does not default chunkLoadingGlobal like Webpack. Without setting this explicitly, chunk runtime globals could clash — especially important in our microfrontend setup.

output: {
  chunkLoadingGlobal: 'rspackChunkLoadingGlobal',
}

7. Testing, Tooling, and Integration

No changes were needed to our Flow, Jest, or E2E tests.
Linting worked fine with eslint-import-resolver-webpack pointing to rspack.config.js.
Tools like Sentry sourcemaps, Webpack Bundle Analyzer, and custom loaders worked without modification.

CI (Jenkins) required no pipeline changes. A simple script swap from webpack to rspack did the job.

8. Final Thoughts

This was a high-impact migration that paid off in less than a week. Here’s what worked for us:

✅ Migrating all apps at once to avoid hybrid states

✅ Ensuring S3 hash collisions were handled early

✅ Relying on plugin parity as Rspack matured

9. What's Next?

Investigating Rsdoctor for further cold build diagnostics
Possibly rewriting one legacy plugin using Rspack’s newer APIs
We currently use Babel to strip Flow types and rely on multiple Babel plugins. Moving to SWC would’ve touched a large surface area — so we deferred it.
Similarly, we stayed with our PostCSS plugin stack for CSS processing and didn’t switch to Lightning CSS, prioritizing migration safety over marginal gains.

Rspack is ready for real-world use — and for performance-obsessed frontend teams, it’s already a game changer.

Should You Migrate?

Here’s how we’d answer it:

✅ Are your Webpack build times >10 minutes?
✅ Do you have multiple independent apps or entrypoints?
✅ Are you not relying on niche Webpack plugins with no Rspack equivalent?
✅ Do you want a faster build with minimal rewrite risk?

If so, Rspack is a strong candidate. You don’t need to switch to SWC or Lightning CSS. We didn’t — and it still paid off.

Thanks for Reading

If this migration helped you, or if you’re considering a similar move, we’d love to hear from you. Feel free to drop questions or share your experience in the comments.

Interested in how our design system tooling or MCP integrations evolve from here? Follow along or check the repo links soon. ✌️

Dynamic content in Github Profile Readme

Diwaker Singh — Tue, 28 Jul 2020 17:06:06 +0000

There is a new thing in the market called Github readme profile. If you are not aware of what it is, please read from here

I came to know about how people are doing really amazing things with github profiles and wanted to do something cool myself.

The idea was to create an image dynamically and show it in github profile. I started with creating and express server on glitch.me and creating a route /image which will serve the image.

Dynamically creating images on node was easy using npm module canvas. More info about it here

I ended up with following code for handling /image route on the express server.

/* width and height of canvas*/
const width = 1200 
const height = 630

const canvas = createCanvas(width, height)
const context = canvas.getContext('2d') 
/* random background color*/
const bgColor=getRandomColor();

context.fillStyle = bgColor;  
context.fillRect(0, 0, width, height)

/* setting the font and text alignment*/
context.font = 'bold 70pt Menlo'
context.textAlign = 'center'
context.textBaseline = 'top'
/* getting randome message if random language*/
const randomIndex=getRandomInt(0,50);
const language=Object.keys(messages)[randomIndex];
const text = messages[language]
const textWidth = context.measureText(text).width
/*drawing text on canvas*/
context.fillStyle = '#fff'
context.fillText(text, 600, 170)
context.font = 'bold 15pt Menlo'
context.fillText(`(${language})`, 600, 280)

context.fillStyle = '#fff'
context.font = 'bold 30pt Menlo'
context.fillText('diwakersurya', 600, 540)

context.beginPath();

/* loading image from github url*/
const myimg = await loadImage('https://avatars3.githubusercontent.com/u/7386665?s=400&u=aaff658cd860d5f886775a293c58e73fa57e7bf9&v=4')
context.arc(600,500,50,0,2*Math.PI);
context.clip();
context.drawImage(myimg, 530, 450,myimg.width * 0.3, myimg.height * 0.3)

/*sending as response to client*/
const buffer = canvas.toBuffer('image/png')
response.contentType('image/jpeg');
response.send(buffer);

What we are doing in this code basically is creating a canvas on express server and attaching a bunch of text/images in the
canvas and finally sending it to client as an image.

Once the server is up and running, We need to make following changes to the readme.md file.

![](https://image-serv.glitch.me/image)

If you are familier with markdown, you know that this line loads an image from url https://image-serv.glitch.me/image.

Thats it. The result will be something like this

Once I saved my github profile readme and reloaded the page, The image started showing up as expected. But on reloading the page, I was unable to get new image with changed color and message.As it turned out, github was caching the image once loaded and using the cached image url in the readme. I tried different ways to overcome this issue but couldn't.

Today I tried out again and turns out that github has removed caching of images. Refreshing the page gives me an image with new message and color.

Checkout my profile https://github.com/diwakersurya and try refreshing the page.

Since the image implementation is on server, there are definately infinite possibilities to think of.

Github Profile Project:

diwakersurya / diwakersurya

My readme profile

                     ⚡ Fun fact: * Refresh page to change the message language and background color. *

View on GitHub

References:
https://flaviocopes.com/canvas-node-generate-image/
https://github.com/Automattic/node-canvas
https://stackoverflow.com/questions/52940095/how-to-style-images-in-a-canvas
https://www.solosophie.com/how-to-say-hello-in-50/