This time I forked a new repository Repository-Context-Packager and cloned it into my local machine. Then I used git checkout to create a new branch for a new feature.
I researched how to create a TOML file. After that, I created a new issue in the original repository to let the host know I had a new feature wanted to add. I implemented it in the forked and cloned version on my computer. As part of the implementation, I added some code in a few files, updated the README, and created a new file called toml-config.js file to read the TOML confirmation file and get the default values specified by the user.
Here is an example of the configuration:
# Sample Config file
# Output file path - where to write the repository context
output = 'output.txt'
# Include all files, ignore .gitignore rules
noGitIgnore = false
# Include line numbers in file content output
lineNumbers = true
# List recent modified files (within last 5 days) only
recent = 5
# Filter files by content pattern "repomaster"
grep = 'repomaster'
When I finished the implementation and pushed my code, I ran into a problem: I was not entirely sure what the host actually wanted. We spent quite a bit of time communicating, even using screenshots to clarify things.
I realized I needed to better understand both requirements and the host's code style. I used some Git commands I had learned a few weeks earlier, such as git commit and git reset, to revert my code to a previous state. Then I modified it again to align better with the host's expectations.
I found that the most difficult parts of open-source contribution are communication, understanding style preferences, and aligning with someone else's vision. Even experienced developers can struggle with communication. That's why I think consistent coding style is another challenging in open source. To deal with this, I made an effort to understand the project and what the owner really wanted, In the end, we achieved a result that we were both happy with.
Next time, I plan to spend more time reading the codebase and communicating clearly before I start implementing anything. One thing my former internship director told me was that in a real project, you spend about 80–90% of the time communicating with your team, and only 10–20% actually coding.
I also learned that TOML configuration files are very helpful for setting default values in CLI tools. Since different users have different needs, a TOML file allows them to customize behavior easily.
Finally, I discovered a new Git command: git remote add. It not only adds a link to my forked repository, but also allows me to track the remote branch from the main contributor. This experience was a great opportunity to deepen my understanding of Git command-line tools and how to use them in real-world scenarios.
Top comments (0)