For this week in my course on open-source development, we were tasked to pick another ssg (static site generator) project and add support for markdown (.md) files and at least one markdown feature. Someone reached out to me about adding markdown support to my ssg (rost_gen) and created an issue for it.
I decided to look at their ssg project (my-button-ssg) which was made using JavaScript. However, since someone had already created an issue for markdown support, I decided to pick another project. After some browsing, I decided to add markdown support to SSGo since it was written using Go. I thought it would be nice to learn more about Go since I had never used it. So, I created an issue, forked the repo, and started working on it.
And the process went way smoother than I thought. The project code was well written and easy to understand. I also found out that Go is a fun language to work with. I was able to add logic to parse Heading1 (<h1>) and Heading2(<h2>) fairly quickly. However, I did run into a minor problem. The header tags in the html that I had created were being enclosed in paragraph (<p>) tags. It turns out that header tags are not supposed to be inside paragraph tags. When the page is rendered by the browser, they are moved out of the <p> tags and you end up with empty <p> tags when you inspect the page using developer tools.
So <p><h2>Heading 2</h2></p> turns into this:
While this does not break the layout of the page, it looks a bit ugly in the inspect view. To fix this, I had to redo and shuffle some logic related to title and paragraph parsing. Eventually, I removed the extra <p> tags, updated the documentation, did more testing, and raised a PR. The author was happy with the changes and my PR was merged without any further changes.
My repo also received a PR. I was familiar with creating PRs and requests for reviews. However, this was the first time I was reviewing a PR. I found some issues related to code indentation and formatting.
So, I decided to use GitHub's feature to suggest the appropriate changes. However, it took me a while to figure out how to do that using the GitHub UI. I also realized that there are single comments, different types of reviews, and that you can see and review the latest commit instead of needing to search through the new changes under the Files Changed tab.
I let the author of the PR know that I had reviewed their PR and they updated the branch based on those changes. However, this resulted in some html file creation logic being duplicated, which resulted in duplicated lines in the generated html:
So, I requested the author to fix these changes and to remove some empty and test files that had been committed accidentally. Once I was happy with the changes, I approved and merged the PR into my repo. And I learned that there are multiple ways to merge a PR into a repository such as "Squash and merge" which lets you "squash" all the commits into one commit's description.
I found this process to be quite fun and rewarding.
Top comments (0)