The Lab
For lab 2 in OSD600 we were tasked with implementing (1) Markdown feature in our previous release from Lab 1. In that lab we created a text file parsing tool that generates HTML files. For this time around we had to add Markdown functionality in someone else's repository.
My partner for this lab was James Mai, and his tool like mine uses NodeJS but his uses Typescript instead of regular JavaScript so that was fun to use. A link to his repo can be found here: TS-SSG
In his repository, I decided to raise an issue to implement Heading support for Markdown in his application. Issue #2. To implement this feature, I mainly had to change the regular expressions used to generate paragraphs. For example, a regular paragraph is:
: content //for regular txt files.
.split(/\r?\n\r?\n/)
.map((para) => `<p>${para.replace(/\r?\n/, ' ')}</p>`)
.join('\n')
As you can see, it's very simple and just wraps lines in a paragraph tag because there are no special symbols in regular text files. However, to implement Markdown, I had to first check if the file had an ".md" extension and if it does, I call a special function to processMarkdown().
${
fileExt === ".md" //if it's markdown do some extra processing.
? processMarkdown(content)
: content //for regular txt files.
.split(/\r?\n\r?\n/)
.map((para) => `<p>${para.replace(/\r?\n/, ' ')}</p>`)
.join('\n')
}
processMarkdown() calls other functions to handle the symbols in a markdown file. It takes a string argument as the raw content before formatting. In this case, the function only calls heading1Markdown() to handle heading functionality.
const heading1Markdown = (content: string): string => {
return content.split(/[\r?\n\r?\n]/g)
.map((line) =>
line.replace(/(^[^#](.*)$)/gim, '<p>$1</p>').replace(/^##\s(.*$)/, "<h2>$1</h2>").replace(/^#\s(.*$)/gim, '<h1>$1</h1>')
).join('\n');
};
This function returns any line NOT starting with a # as a paragraph for now because Heading is the only thing implemented. Then, the next regexp replaces any lines with 2 # as an h2. Then, any line left over with a hash must be h1. If there were more headings, you could work your way down from h6 to h1 and do the same method.
The experience of contributing to someone's code was a very fun experience. One of the challenges I faced at first was understanding the flow of someone else's logic. For example, my partner used many more functions than I did, and so when I wrote my code for their repo I added functions and tried to do things a similar way.
In the end it is a good thing though because functions helped keep his code organized and gave me some ideas about how to use them in my own code to reduce my repeated logic.
Some of the pull requests on my own repository include one where my partner had to fix the name of the HTML file generated from .md inputs. Pull Request 11 . That was really the only thing I needed my partner to change because we both asked about the code we were writing along the way so the pull request merge was smooth.
Overall I wouldn't do anything differently because I learned a lot about forking, cloning, pull requests, and merging changes into my repository.
Top comments (0)