text-ssg VS cmd-ssg

GitHub: @Kevan-Y Repo: https://github.com/Kevan-Y/text-ssg Thanks contributor: @irenejoeunpark @DukeManh @AndreWillomitzer

For my pull request to his project text-to-ssg I tested one of his functions called getAllFiles(). I wrote an expect() function expecting the files function to throw if it does not find the file (it's not the function itself throwing, but the fs.readfile function throwing).

Issue: https://github.com/Kevan-Y/text-ssg/issues/26 Commit: https://github.com/Kevan-Y/text-ssg/commit/2ca3d50f599b95620c1d28782fac9af9275746b8

I decided to use a third party package to have the full markdown feature + highlight with highlight.js. Issue#24

After making all the commits for the above change. I wanted to squash into 1 commit. I first run the command git rebase -i master and pick the commit that I needed to combine together to squash and leave one commit to be pick. After saving the files I wasn't happy with the name of the commit, I run the command git commit --amend and changed the name. (b092da9)

So I started to create a branch call issue-19 for my Issue#19 then another branch call issue-20 for my Issue#20. I checkout issue-19 and started to add my language support for HTML tag. After finishing implementing my feature 8bcd08a, I committed my changes and switched to my issue-20 branch where I have to add a support markdown horizontal line. After finishing implementing this feature 9bee88d. I found out I have to go back to my issue-19 branch and add another commit to update documentation f2608c4. The same thing for issue-20 bc7ec05. After all, was done, I checkout my master branch then merged my issue-19 branch first which I did not have any issue merged it since it was a Fast-forward merge. But when I merged my issue-20 branch I had to resolve the conflict first do a commit for resolving the conflict 7ea3f6e, this is also called a 3-way-merge. After all, this is done I pushed my master branch to remote, then closed my issue + adding a message Closed by .

Duc Bui Manh has to implement his markdown feature to my code. He first created an Issue#15, then created a pull request PR#16 for his change. The way of implementing a smarter than my way using some regex. I pull his code and do some testing on my side. I found that the markdown for the link was wrong, the href contains some tags. Also, the heading was wrapped with

After I reviewed Eugene code, he had to review mine. I always like people to review my code and tell me what I can improve on. For me it is a way to learn how to write efficient code in the future. When Eugene testing my SSG code, even with some error checking I put in place he was still able to find some bug in my code. One of the issues Issue #1 he found was my code wasn't checking recursively for any .txt files. One of the solutions is to implement a recursive check to check if there is any .txt file in the children's directory. The second big bug Issue #5 was that the generated HTML file does not pass HMTL5 standards. I notice that for a .txt file that has a name with space, it will convert to an HTML file with name + space. The solution was to replace all space with hyphens when creating the HTML file. The same logic applies to folders too.

Sample of file generated: https://text-ssg.vercel.app/ GitHub Repo: https://github.com/Kevan-Y/text-ssg

After that, I tried to make a test that with errors to check my CI. I updated my code so that it will have an error when I run the tests. And then I made a PR to my repository. When Github receive my PR, it will run the workflow automatically. It will check my PR to make sure it won't crush my original program. Well, there was an warning showed up as I expected: And because there was an error with the PR, there is no way I can merged them to my program. Therefore, I just reset the wrong code to the right one. Then I made the PR again. And this time, it didn't show my the error anymore and I can merge it to my repository. Moreover, for this Lab 9 we need to test other people's CI as well. I found my partner Eugene through Slack. And we talked about what is the good idea for adding a new test function to each repository. Personally, I just added a new small test function to my partner's program. It was a test function about testing what will happen if the user use the function with empty argument. Due to this is not a program that I made, I need to go through my partner's code and followed his logic to made up a test. It's slightly different when adding a test function to a program that you never participated in. But it became easy after you communicated with the program builder!

I have choose to work on JavaScript SSG application that created by Eugene Chung. The testing setup and environment is completely different. He has configured the Node environment whereas I have configured .NET environment on CI. Also the testing environment is different. I have used XUnit for unit testing whereas he has used the Jest for unit testing. However, I have change to work Jest for unit test on WEB422 and previous contribution on Telescope. Also he has excellent CONTRIBUTING.md for providing how to test in his application. Therefore, the testing on my partner's repo is straightforward.

This week, I've been contributing to another static site generator (SSG). I've picked up a few things that may be useful to first time open source contributors:

Testing and reviewing code might sound difficult, but with my previous co-op experience. I got better and better to read someone else code. It is like reviewing a Pull request. No code is perfect, they will be always a bug, improper formatting, unnecessary comment. One of the issue reading his code was the code wasn't properly formatted and they are random comment all over the place. Issue #2, Issue #3. After creating those issue Eugene fixed within a day and the code was much nicer to read.