Introduction
Hi! My name is Harshil. I am currently enrolled in the Open Source Development course at Seneca College. In this course, we are required to contribute to different open-source repositories every week. So far, I have contributed to more than 10 issues across 6+ open-source repositories. You can find the full list of my contributions here: List.
During my most recent contribution to Chatcraft, I realized that contributing to significant issues can be challenging, but true learning happens when you push yourself outside your comfort zone. For that pull request, I spent over 35 hours working on it, as I received numerous change requests from the maintainer. The most important lesson I learned is that big things take time and persistence.
With this insight and my growing experience in open-source contributions, I started searching for a big issue to tackle next. My goal is to contribute to something that I will genuinely be proud of.
Finding the Right Issue
I started exploring different repositories and their issues. Initially, I looked for issues in the repositories I had already contributed to, but I couldn’t find any suitable ones. Trust me, finding a good issue to work on is a challenging task. I also tried checking out various large repositories, such as React, VS Code, and .NET, but I still couldn’t find anything that matched my skills and interests.
Finally, I discovered a good issue in the Node.js repository. Node.js is a cross-platform JavaScript runtime environment that executes code outside of a browser, built on Chrome's V8 engine. I have worked extensively with Node.js, having built many projects using it, but I never imagined that one day I would get the opportunity to contribute to its core development. I reached out to the maintainer to ask if I could work on the issue.
Understanding the Issue
After receiving the maintainer's response, I started looking into the issue. The title of the issue is "Add a level parameter to test runner diagnostics." Initially, it was difficult to understand the issue based on the title and description, but there was a reference to a related pull request that provided more context. Upon reviewing the pull request, I discovered that the issue was related to the test_runner module in Node.js.
The Node.js test_runner is a built-in module that enables developers to create, manage, and execute JavaScript tests. It supports various testing workflows with features like TAP output and subtests. You can learn more about the test_runner here.
The issue suggests adding a level parameter (e.g., debug, info, warn, error) to the diagnostics functionality of the test_runner. This enhancement would allow developers to apply color coding to the output based on the severity of messages, making it easier to differentiate between message types. The idea originates from a related issue where errors in test coverage thresholds were displayed in blue instead of red, leading to confusion during code reviews and debugging in CI pipelines. Here is the original issue.
For example, if I am developing a project and using Node.js for testing, I might write some test cases and require all my files to have 100% test coverage. Using the test_runner, I could pass the flag --test-coverage-lines=100, which compares the actual coverage to the expected value. If the actual coverage is less than expected, the test coverage report currently prints an error message in blue. This color is not noticeable, causing developers to mistakenly believe their code meets the coverage requirement. Moreover, if this flag is used in a CI pipeline, the pipeline could fail unexpectedly, creating further confusion.
Planning the Fix
After that, I reviewed the files involved in this issue and posted a message in the issue thread outlining the changes I was planning to make.
The maintainer responded promptly, suggesting some modifications and encouraging me to start working on the issue and submit a pull request.
First, I wanted to try the --test-coverage-lines=100 flag locally. To do this, I created a sample JavaScript repository, added a sample file, and wrote a test case file to test that code. However, when I tried using the flag, I encountered an error.
After reviewing the original issue, I noticed that they were using Node.js version 22.. To match their setup, I installed Node.js v22. using Node Version Manager (NVM) and switched to that version.
Despite this, the flag still didn’t work. I tried various troubleshooting steps, but none of them resolved the issue. Eventually, I found a blog that explained how to set up and run the Node.js test runner properly. By following the steps outlined in the blog, I successfully set up the test runner.
Here is the result:
The error message was printed, but it appeared in blue, which confirmed the issue I needed to address: changing the color of the error message to red by adding level in diagnostics.
Conclusion
This contribution was a perfect example of how open-source development combines problem-solving, collaboration, and persistence. While I faced challenges setting up the environment and understanding the issue, the process deepened my understanding of Node.js internals and taught me how to navigate complex problems effectively.
In my next blog, I will discuss the steps I took to address and fix this issue. Next blog can be found here: Contributing to Node.js: Implementing Dynamic Colors for Test Runner Diagnostics (2/3)
Top comments (0)