In this lab, I contributed a new feature to a new project repopalI have not worked on before. The feature I worked on was TOML config file support, so that users can store default options in .config.toml instead of typing everything on the command line.
When I first cloned the repo, I spent time understanding the file structure. I wanted to avoid breaking anything, so I carefully checked where CLI options were parsed and where defaults were handled. One challenge was that the repo mixed JavaScript and TypeScript. I am not very familiar with TypeScript, but since the main entry point was written in TypeScript, I decided to maintain consistency and implement my feature in TypeScript too. Luckily, the difference between JS and TS wasn’t too hard in this case, since most of the logic was just function calls and type definitions. To implement this feature, I do find the useful library called @iarna/toml. This required me to learn how to work with TOML parsing in Node/TS, which was a new experience. I also had to be careful to keep the code style consistent with the original author.
I do feel much more comfortable when using Git. Creating a new branch, committing small changes, and pushing them felt natural. And for reviewing and testing via remotes, I’ve done this process a few times now, and it feels very smooth. I don’t even need to look up the commands anymore. This gave me confidence that I can handle collaborative workflows and code reviews in real open source projects. One new thing I learned this time was the “Draft Pull Request” (or “Mark as progress”) feature on GitHub. I hadn’t used this before, but it was very useful to open the PR early and keep track of my progress while making more commits. This also makes it easier for the repo owner to see work-in-progress changes.
In addition to contributing, my own repo also received a PR from another student. To test their work locally, I had to add their fork as a new Git remote, fetch their branch, and then check it out. Reviewing someone else’s changes was a valuable experience. I had to check if their code matched the project’s style, tested it locally, and left some review comments. I think that code review is not only about correctness, but also about readability and maintainability.
Top comments (0)