mh-ssg VS cv-ssg

This week, I've published my 1st package on npm - mh-ssg - a static site generator CLI.

I also worked on another project, mh-ssg, and added tests to this project as well. I created unit tests for a function called processFolder(). This function accepts an input folder path, output folder path and stylesheet URL. I created two unit tests, one which tests when a valid input folder containing files is passed to the function and one which tests when a non-existent folder is passed to the function. The function logs a message to the console depending on how many files are saved in the output folder, so the tests I wrote tested for these console logs.

For this lab, I picked Jest as the testing tool for mh-ssg. This is a popular Javascript testing framework thanks to its simplicity and ease of usage.

To maintain the quality of source code, I added a formatter and a linter for my project.

Throughout the previous week, I was exploring Docusaurus and found that they have a feature to support static files. I find this feature very useful for any static site generator since images, favicons, stylesheets, etc. are very common parts of a webpage. Therefore, I decided to add this feature in my tool.

As new features are added to the tool, I realized that the logic is not clear anymore and some parts were duplicated, making it inefficient and hard to maintain. This time, I decided to focus on removing those duplications by moving the statements to the appropriate place and extracting function for reusability. All the refactoring was done through a single commit with the help of git rebase.

Luke also implemented the same feature for my project. His code in general was good but I suggested some changes including separating modules and combining functions to remove code duplicates.

After looking through my classmates' projects, I decided to work on Minh Hang's static site generator and filed an issue to her repo.

In the last update, my friend - Dustin - helped to add Markdown as a valid input for my tool. Markdown syntaxes are different from HTML syntaxes and he has worked on converting some of them. This time I decided to add two more:

I've been sending a lot of pull requests but this was actually my first time receiving one 😄 and Dustin was my first contributor. He also proposed to add Markdown support for my tool and to parse all the headings, bold, italics and link from markdown into the corresponding HTML tags. I scanned through the pull request and found some minor issues, including missing new feature in documentation and missing the handling of the output file name. We also had different opinions about the implementation of .txt file and .md file. However after discussion, we came to agreement and I approved his changes.

After forking and cloning Dustin's repo to my local machine, I read through the CONTRIBUTING.md to set up and run the tool to make sure it work correctly.

As I'm using Javascript for my project, I have Prettier as the default code formatter.

Fully support for markdown file

Before using classes I will have around 6 files in my helpers folder here

In lab4, I have another chance to contribute to my classmate's repo. This time I am going to add support for config files to Dustin's repo.

Her issue link Her pull request My repo

The 2 issues I was talking about: First one Second one

As a part of the Open Source Development course that I'm taking, this week I needed to make some contributions to someone else's repo. As I was looking through some projects about CLI for Static Site Generator, Dustin's repo immediately caught my attention. The code is also written in Javascript but Dustin used commander, which was different from me. I thought contributing to his repo would help me learn something new so I filed an issue to add a new feature to his tool.

Well, it was very new for me to test review someone’s code as I was doing it for the first time, but I found myself comfortable and confident enough to test his work after reading this post in which he explains how to use his tool. The tool documentation being so good, it was easy for me to install, run and test in my local machine. Well, everything worked perfectly and according to the requirements, and that did not surprise me, but the surprising part was it was done so amazingly that it gave a hard time to find 3 issues in the code! The 2 of the 3 issues I found were related to commandline options and the third one was related to version. The options part had an issue that the output on the terminal was not align which I according to me, if improvised can give a better look of using the whole tools. The second issue regarding options was that the tool was using commandline arguments as program variables instead of options. Improving this can make the work easier for the developer and can also make the work more organized. The final issue was related to the tool version. The program was not able to pick the package.json file which gave an error when I tried seeing the version number through the commandline.

MY REPO RITIK's REPO