Effective PRs, Code Reviews, and Issue Fixes

Introduction

This week I had the opportunity to work on a CLI tool maintained by Peter Wan, the CLI tool was mainly built using JavaScript, it had a CI Pipeline that ran a test suite whenever a Pull Request or Push was made to the repo

The main goal of this tool was to generate a comprehensive description of files that were being passed to it, so it was prompting LLM API to generate the documentation and then based on the inputs the documentation will either be piped down to a file or will be shown on the terminal

Task at Hand

The CLI tool would benefit from a feature that allows users to see how many tokens are consumed during a prompt to the LLM. To address this, I raised an issue on the repository to add a -t, --token option that would enable this functionality. I also asked the maintainer if he could assign me to work on the feature. Peter, the maintainer, responded quickly, letting me know I could proceed with the implementation and suggesting that I use the shorthand -tkn, as -t was already being used to set the temperature for the LLM.

Codebase Exploration and Feature Addition

To start working on the issues, I followed the following steps to get the repository on my machine

1. I forked the repository to get a copy of it on my account
2. I cloned the repository on my local machine
3. I went through the readme, and it was comprehensive on the instructions part as to how to get the CLI tool to work on my machine.
4. I had some issues with the npm link command, so I got on a call with Peter, who helped me to fix the issue .

Then came the most interesting part: exploration. Since the codebase was in JavaScript, I was quickly able to understand what was happening, but to speed things up, I commented out a function flow to see how data was being passed between different functions.

One of the most interesting aspects of the code was that it used two different API providers. I had prior experience working with Groq, but the Gemini API was new to me. So, I went through the documentation, explored its functions, and experimented with the Gemini API to get a better understanding.

What I appreciated most about the codebase was how well-organized it was, with different functions and helper functions placed in dedicated files. There was a file to configure the CLI tool, a file for API helper functions, and a file to handle the CLI function flow. This structure made everything much easier to navigate.

My goal here was to make the feature work with fewer code additions, I added some comments for my personal use, and then after that, the task was to include the token information and parse the data sent back to me by the API's

For Gemini

For Groq

The final step was to output the token count in the terminal. However, the parsed data couldn’t be displayed directly, so I created three variables to capture the relevant values, which I could then output to the terminal.

After this, I had to to fix the test cases in the test suite to match the new number of options that are available to the users which now was 8 (including -tkn,--token).

These were the steps I took to successfully implement the feature in the codebase.

Pull Requests (PRs)

I was familiar with PRs previously, but the learnings that I gained from working with a different person on resolving and getting feedback on my PRs were great.

I made an issue while I was working on the forked repo, what I did was I started implementing the feature straight on the main branch, which wasn't right, as I would be restricting the repo to fetch any updates made on the main branch from the upstream, so I quickly resolved this issue, started working on issue-21 branch.

After I was done implementing the feature, I raised a Pull Request, but it failed to pass a check from the CI pipeline, so I got feedback from Peter, who told me that it would work if the test suite was suited to meet the requirements of the updated codebase.

After that, I went on to fix the test case, which subsequently led to my feature getting merged into the main repository via a PR.

I would say the best part of this was the constant communication with the maintainer, Peter and also understanding my mistake of working on the main branch in a fork

Issue Requests On My Codebase

Peter assisted me in adding a -t/--token flag in my CLI tool,DialectMorph, the experience was similar to how it went with Peter's CLI tool.

However, we encountered an issue that was new to me. As a Mac/Linux developer, I rarely use WSL or PowerShell to run code. Typically, I would create a Dockerfile in the codebase to provide testers with an isolated environment for running the code, but this time, I was saving the Dockerfile for later releases. The issue arose because my CLI binary wasn’t working in a Windows environment.

To resolve this, Peter and I had a troubleshooting session on Discord. Our approach was methodical—working step by step, documenting any issues we encountered along the way. Though it was time-consuming, we eventually managed to fix the problem.

Once Peter finished adding the feature to my codebase, he submitted a pull request PR. The PR was comprehensive, as he also updated the README.md file to include a description of the new functionality.

Learning So Far

So far, I’ve learned the importance of clear communication and proper workflows when collaborating on projects, particularly the need to use feature-specific branches instead of working directly on the main branch. I gained hands-on experience troubleshooting cross-platform issues, especially for Windows environments like WSL and PowerShell, which pushed me out of my comfort zone as a Mac/Linux developer. Working with different API providers, such as Groq and Gemini, helped me adapt to new technologies, while the experience with CI pipelines reinforced the importance of automated testing in maintaining code quality

Thank you for sticking till the end!