My first contribution to another open source project

I recently contributed to a repo named TILvert -- a cmd line tool that converts txt files to HTML files, to add a markdown feature to it, specifically parsing links that are enclosed in []() which are then converted to anchor tags.

The process to add a feature to the repo included quite a lot of steps, and are explained as below:

1. Forking a repo. This was my first time forking a repo. Initially I didn't understand the reason to do this but then came to know that any time we'd want to work on an open source project, generally people don't have permissions to commit directly to a project, and have to go the route of forking are repo and filing a PR to get the code changes merged.
2. Creating an issue to track a feature implementation, which can be found here -> Adding markdown support (Lab #2). This was a first time for me too. I learnt that the idea of filing an issue on a repo is a formal way of saying you have shown interest in their repo and discuss in detail what and how you'll be fixing a bug or adding a new feature.
3. Creating feature branch. This, I've done one too many times. The main idea is to have a separate branch for a bug fix or feature implementation so that code changes can be tracked and are only merged to the main/master branch when it's tested and reviewed throughly before making it part of the software.
4. Testing code changes which is a vital part of software development in general. I tested the local code changes over and over again to make sure I didn't break any existing functionality in the application and also made sure that the new changes work as they were expected to work. I used a markdown file to test code changes, specifically written for testing purposes which included all the test cases for converting markdown links to anchor tags.
5. Creating a Pull Request(PR) which can be found here -> added md link support. This, I've done it one too many times but never added as many details as I did for this PR. The idea to create a PR is to inform the owner of the repo that you've made changes which you'd like them to provide feedback and merge it if everything looks good, mention exactly which changes were made, how they were implemented among other things. Since it was a visual feature, I also added a screenshot to show how the feature looks like with the new changes in place.
6. Linking Issue with PR. This was a first one for me. I learnt that the need to link an issue with a PR is for better traceability and once an issue is merged it also helps close an issue automatically.
7. Getting feedback from owner and implementing them. This is a very important process in getting code changes merged to the repo since ultimately its their repo and its their decision to accept or reject the incoming changes. This step also includes merging feature branch to repo's master branch so that the feature gets deployed successfully.

The way to go about this was to use regular expression to parse the markdown links to anchor tags. Most of my logic was to come up with a regular expression that helps me extract a link; to create an anchor tag I used an existing method where I pass in the content that is to be added to the anchor tag and it returns me the tag in string format. I generated this regular expression /\[([^\]]+)\]\(([^\)]+)\)/g to match and parse markdown links. I've used the idea of groups to extract the link and the text of the link so that I can pass it accordingly to generate anchor tags. The first group, \[([^\]]+)\] captures the text of the link that goes between the open and closing anchor tags, the second group \(([^\)]+)\) captures the link itself and this regular expression looks for the pattern globally, across the paragraph to find all the links. Regardless of how may links are there in a paragraph it'll find all of them, iterate over them, generate anchor tags and replace the links in place with the anchor tags before a paragraph gets converted into html supported paragraph tags.

Besides, I learnt to understand how the existing code is written so that I'd touch only the code that needs to be changed. I also tried to follow the existing styling, naming conventions, usages of existing functions, etc., as much as possible and so that I don't haphazardly start making code changes.

Note: No one has yet filed an issue or created a PR on my repo at the time of writing this blog.