This week, I was tasked with adding config file parsing to another student's ssg. I chose to add this feature to Oscar's my-button-ssg. The config file would contain the available options for the ssg in JSON format. I created an issue and began implementing the new feature.
Since the project was written in JavaScript, I found it quite easy to add config parsing to it. I read the contents of the config file and parsed them into a JSON object. After this, it was pretty simple to read the provided options from the JSON object, perform some null checking, and generate the html file(s). So, I committed my changes and created a pull request and asked the author for a review. Though with how smoothly the coding part went, I had completely forgotten to update the documentation. Once that was updated, my PR was merged into the main branch.
My rost_gen ssg project also received a PR about adding config file parsing. After reviewing the changes, I decided to test it locally by setting up a tracking branch using git. This was fairly simple to do, and I can't believe I did not try this before. Since I have not added any automated tests, I previously did this by looking at the code. However, as more features get added, it is not possible to check if the code will work as you think. By using a local tracking branch, I was able to easily test the changes and find some formatting issues by using VS code's auto formatting. I requested the author to resolve these and merged the PR by merging the branch into the master branch.
Overall, I found the process to be fairly straightforward. While I like the fact that I can close a PR by merging the branch locally and pushing the changes, I still prefer to use the GitHub UI as I find it easier to navigate.
Top comments (0)