Yeayy, my PR was merged by the legend Zack Jackson, Core Maintainer of Webpack and Rspack. See the PR.
This journey into open-source contribution began unexpectedly, driven by an issue in my React Router v7 a.k.a Remix. I was facing a significantly large bundle size, partly due to my company's MUI-based UI library. Furthermore, Vite, my current bundler is strict, the mix of ESM and CJS modules produced by MUI, often leading to build complaints. This prompted me to seek an alternative.
After exploring various bundlers, Rspack seems promising. My initial tests with a plain React app confirmed its incredible performance – even faster than Vite! Encouraged, I looked into integrating Rspack with React Router v7 and discovered . However, my enthusiasm was short-lived as the app immediately crashed with a . This was the starting point of my contribution journey.
Unraveling the Mystery: From Error to Root Cause 🕵️♂️
I immediately delved into the GitHub repository. A quick scan of the issues section revealed that I wasn't alone; others had encountered the exact same TypeError. The issue remained open, and previous attempts to fix it by downgrading versions hadn't yielded success. Observing the lack of progress on the existing issue, a thought sparked: "Could I fix this?"
Driven by curiosity and a desire to contribute, I cloned the repository and began my investigation. I focused on tracing the error. It was a challenging task, involving extensive code reading, but eventually, I pinpointed the root cause. That night, I slept soundly, knowing I had cracked the first part of the puzzle.
The Fix: Debugging, Local Testing, and Validation ✅
The next day, the real work began. Identifying the root cause is one thing; fixing it is another. My strategy involved strategically placing numerous statements to understand the code's flow and the build process. I gradually narrowed down the problematic area, allowing me to focus on a small, manageable section of code. By meticulously analyzing each line, I identified what was missing and how to implement the correction.
To verify my solution, I used , a handy command that allows you to locally link a library to your consumer application. Running my React Router v7 app with the linked version, I witnessed the fix in action – the app now ran without the error! To ensure this wasn't a fluke, I unlinked my local version, confirmed the error returned, and then relinked, seeing the fix persist. This rigorous testing gave me full confidence in my solution, and I began planning my Pull Request.
Crafting the Pull Request: My Secret Sauce 👨🏻🍳
Contributing to an open-source library requires adhering to specific guidelines. After familiarizing myself with the project's contribution rules, I prepared my branch and committed my changes. When it came to the Pull Request description, I knew the importance of clear, convincing communication. It's common that you need a way to convince the reviewer, and this is especially true if it's your very first PR to a library. Your primary job is to make the reviewer confident in shipping your changes.
For bug fixes, I have a format that I've found has a >90% success rate :). I split the description into three key parts:
- Issue: Clearly state the problem, ideally referencing the existing GitHub issue.
- Root Cause: Explain the underlying reason for the bug with specific details.
- Solution: Describe your proposed fix and how it addresses the root cause.
Beyond the structured description, providing ample proof – be it images, videos, or detailed testing notes is crucial (my Senpai post a great article about this, check this out). The goal is to make the reviewer confident in merging your contribution without overwhelming them. After submitting, it's typically a brief wait for feedback, often just an "LGTM!" (Looks Good To Me!) :), before the PR is merged!
A Shift in Perspective: From Observer to Contributor 💡
Honestly, contributing to an important open-source project like this was never something I imagined doing. The sheer size and complexity of the OSS repositories can be incredibly daunting. But now, having successfully navigated this process, I realize it's entirely achievable. My experience has fundamentally shifted my perspective: from asking "When will someone fix this bug?" to "Can I fix this bug?".
I hope sharing my journey proves useful and inspires you to take your first step into the rewarding world of open-source contributions.