Mayank KumarThis week, I was tasked with adding a new feature to a peer's repository, and have them implement a feature in my repository as well. The goal was to locally test the changes in my repository by tracking the remote branch created by my peer. This experience not only helped me learn more about collaborative development but also provided insights into effectively using remote branches in Git.
Opening the Issue
I began my journey by choosing Anh Chien Vu's VShell repository, a CLI tool designed to process input source files with a Language Model (LLM) to generate a README file. Written in JavaScript, it utilized the commander package to set up the CLI - similar to my own project, dev-mate-cli. I opened a new issue requesting the feature to use configuration options from a .toml file located in the user's home directory, as outlined in our course lab.
Support using TOML config file
#18
This feature request is to add support for configuration files in TOML format, which offers a more readable and user-friendly syntax for complex configurations.
- Implement functionality to read and parse TOML configuration files.
- Add validation for required configuration fields within the TOML structure.
- Update documentation to include instructions for using TOML configuration files.
Use Case: Users who prefer TOML for its simplicity and readability can use it as an alternative to other configuration formats, enhancing flexibility in configuration management.
Working on the Issue
After opening the issue, I forked the repository and cloned it to my machine. I created a new branch called feature/issue-18 and added a new file for configuration settings related to the model and temperature of the LLM in TOML format.
To illustrate my implementation plan, I created a draft Pull Request (PR) explaining my proposed changes to the repository owner. During this process, I explored various TOML parsers in JavaScript and ultimately selected smol-toml for parsing the TOML configuration file.
I set up a function to load options from the configuration files, establishing them as default parameters for the commander program in case arguments for the model and temperature were not passed via the command line. If arguments were provided, they would take precedence over the configuration file. Throughout this process, I ensured that my changes were minimal and adhered to the original code style.
Once I completed the implementation, I updated the README to reflect the new instructions and pushed the topic branch to GitHub, making the PR ready for review.
Support configuration with TOML file
#19
This pull request aims to add support for configuration files in TOML format, which offers a more readable and user-friendly syntax. An open-source TOML parser - smol-toml is used as a dependency for parsing the configuration files.
Fixes #18
- [ ]
.toml: Added a new configuration file in the root directory of project. - [ ]
server.js: Added parser function and made option in the config file default for program - [ ]
groqConfig.js: Replaced hard-coded model with model from program options - [ ] README.md: Added information about the use of configuration file
- [ ] Tested multiple scenarios and edge cases manually, no issues found
This change will allow user to define configuration for Chat Completion API within a TOML file instead of passing them via arguments on commands line.
- Breaking changes: No
- Documentation updated: Yes
- [ ] Code compiles correctly
- [ ] Code adheres to the style guidelines
- [ ] Documentation updated
- [ ] Ready for review
Please let me know if you want to omit/add any options in the configuration file.
Addressing an Issue
Upon reviewing my PR, Anh quickly pointed out that my changes were causing the tool to search for the TOML configuration in the project's root directory instead of the user's home directory, as specified in the lab instructions. Realizing my mistake, I carefully revisited the requirements and made the necessary adjustments.
Using the Node.js os module, I modified the function to correctly search for the configuration file in the user's home directory. After implementing these changes, I updated the README again and pushed the new modifications, asking for a review. A small change was requested afterward, which I promptly addressed, and the PR was eventually merged after being tested locally by Anh.
Testing the Remote Branch
While I was implementing my changes, Anh was concurrently working on adding the same feature to my repository. My project already supported using a config.json file located in the project root directory, and Anh added support for TOML files from the home directory.
To facilitate testing, I added Anh's forked repository(named it toml for ease) as a remote for dev-mate-cli on my machine using:
git remote add toml https://github.com/AnhChienVu/dev-mate-cli_fork.git
After fetching his fork, I created a new tracking branch from his issue branch:
git checkout -b tomlb toml/issue-17/toml-config
I thoroughly tested the changes, ensuring everything functioned as expected. After reviewing the code style, I made a couple of change requests. Once those adjustments were completed, I tested again and then merged the changes into the main branch of my origin using:
git merge tomlb
After merging, I pushed the main branch to GitHub, which automatically closed the pull request created by Anh. The same process was followed for my branch in VShell, resulting in a successful merge.
This experience taught me the importance of using remote tracking branches for testing changes locally before merging PRs. By implementing the feature and collaborating with Anh, I learned valuable lessons about Git workflows and the need for clear communication when working in a shared codebase. In the future, I would aim to double-check feature requirements and instructions to avoid any initial missteps.
I look forward to applying these lessons in future projects and enhancing my collaboration skills further.
