Creating First Pull Request

Recently, I had the opportunity to create my first ever pull request for a peer's open-source project, codeshift, created by Uday Rana. codeshift is a command-line tool that transforms source code files into any requested language using GROQ's chat completion API. I submitted three pull requests (PRs) to this repository - one for a new issue I raised and two for existing issues. The process gave me valuable insight into collaboration and adapting to another developer’s codebase.

The Pull Requests I Created:

1. Adding Token Usage Flags:
   One of the key features I worked on was adding the -t and --token-usage flags to the CLI, as specified by our lab instructions. This allows users to toggle API's token usage report in the command line.
   You can view the PR here: https://github.com/uday-rana/codeshift/pull/11

2. Preventing Output Overwrites:
   Another issue I tackled was adding logic to prevent output files from being overwritten when multiple input files were passed to the program. This ensures users don’t accidentally lose their data.
   You can view the PR here: https://github.com/uday-rana/codeshift/pull/13

3. Disabling Output on CLI
   The third issue that I resolved was a relatively smaller problem. When an output file was provided in the command arguments, the problem wrote response to both CLI and output file which was not the expected behavior.
   You can view the PR here: https://github.com/uday-rana/codeshift/pull/14

Since codeshift was written in JavaScript and I was working on dev-mate-cli which is a TypeScript project, I was able to jump into the code fairly quickly. However, even though I thought my changes were minimal and aligned with the existing codebase, Uday requested a few changes. He preferred silent logging and had a different approach to file overwriting logic, which I hadn’t accounted for.

Challenges and Learning

I quickly realized that contributing to someone else’s project requires more than just solving the issue. There’s also a matter of following the owner’s coding style and understanding their specific preferences. What helped me was communicating directly with Uday about the changes he wanted. This dialogue helped clarify his expectations and allowed me to adapt my code accordingly.

Next time, I'll invest more time in understanding the coding style and preferences before submitting a pull request. This will help me avoid extra revisions and get the request accepted quicker.

Receiving Pull Requests

I also had the experience of reviewing pull requests for my own project, dev-mate-cli . Uday submitted two requests:

1. Token Usage Flags:
   His first PR was to add token usage flags to my project, which I accepted without any changes because it aligned perfectly with my coding style and the project requirements.
   Link to the PR: https://github.com/mayank-Pareek/dev-mate-cli/pull/12

2. Centralizing Program Metadata:
   In his second request, Uday centralized the program’s metadata (name, version, description) to keep everything in sync with package.json. Initially, he only included the name and version, but I requested that he add the description as well. He made the changes promptly, and the PR was merged smoothly after review.
   PR link: https://github.com/mayank-Pareek/dev-mate-cli/pull/13

Collaborating with Uday on both codeshift and dev-mate-cli has been a great learning experience. Not only did I get to learn working with pull requests, but I also learned how to communicate feedback effectively. Moving forward, I’ll definitely put more effort into understanding a project’s guidelines and coding conventions before diving into code. It’ll make the process faster and reduce the number of revision cycles.