mini-ssg VS jellybean

#issue-23

Luckily, my newly added test case didn't fail the CI workflow, so my PR got merged eventually.

There are different options to set up GitHub Actions. You can either choose to do it manually or choose from numerous templates. My project, MINI, works just fine with the Node.js template:

With the features in mind, I began by creating an issue on my repo, detailing what I needed to do, and providing suggestions or resources to help me accomplish it. Implementing the code was not too difficult, and I realized that I could add more features to improve my SSG. After being satisfied with how the markdown support works, I began editing the issue to include support for static assets. It is a nice feature to have in my project, as I think images and favicons are common in most web pages today.

My project 💻: mini-ssg Rebase commit 📝: f42e5b6

This week, I decided to work with Luke to implement the new feature of adding support for config file to his SSG tool. The implementation didn't take much time since his code is very clear and doesn't have any major bugs to worry about. With the new feature, the tool now accepts config JSON file when option --config is used. This option will read the config file and generate HTML files based on the options provided within the file, and ignore all other options passed in from the command line. After some modifications, he agreed to merge my pull request

In my static site generator, MINI, I decided to implement 2 new features and created different branches for each of them:

I decided to work on Minh Quan's repo in this lab and implemented Heading1, Heading2 and Links syntax features for his SSG.

Similar to what I did, Vivian also reached me through Slack and asked to review her pull request. While going through the changes that my partner made, I noticed some minor issues. I decided to leave some comments at where they were, explaining how I wanted to change them and included some links for further reading/reference. With the feedback, Vivian quickly fixed the issues and asked me to looked at the code again. Additionally, I asked her to send me on Slack some screenshots of her tests and outputs. After verifying that everything was working as intended, I decided to merge the pull request and not forget to leave her a small token of appreciation.

In testing Luke's code, I found that the --version flag did not correctly print the program name. In addition, his program was not able to correctly read file names that contained spaces. Finally, I noticed a formatting issue in the generated html code. Luke used a library called create-html, which made generating the html very simple, but the formatting of the output was a bit messy (for example, incorrect indentation or a lack of spacing).

After writing a few unit and E2E Integration tests for my static site generator, Jellybean, last week, this week I added Continuous Integration to the repository. It was very easy to set up and is useful if you or other contributors forget to manually test while making changes. It ensures that changes or pull requests made to the main branch are automatically tested by running a workflow.

For Leyang's project, I found that getHtlmlTitleBody() was not tested yet so I decided to contribute some tests to it. This function accepts the content of the file as a string and a boolean indicating whether it's a text file or not, it then returns an object with 2 properties: title and body.

This week, I continued working on my static site generator Jellybean and focused on creating and running tests for the program. I decided to use Jest for testing, mostly because it was what was recommended and I have tried other tools such as Jasmine and Karma before, but not Jest, so I thought this would be a good opportunity to learn how it works.

For my own static site generator, Jellybean, one feature of Docusaurus that I wanted to implement was full markdown support. This is because my static site generator previously only had partial markdown support, which is not very user-friendly. Thankfully, there are a some great open-source libraries which can provide full markdown support and I decided to use markdown-it for my project.

It was my first time learning about interactive rebases and I found this process to be so useful as it gives you so much freedom in customizing your commits. I used the interactive rebase command (git rebase main -i) to squash all my commits into a single commit. In addition, I used the git commit --amend command to modify my commit message and add more details. After this exercise, I feel so much more confident in using rebases to modify my commits and project history.

This week, I worked on Leyang Yu Static Site Generator project called jellybean. I added a new issue on her repo to let her know that I wanted to add a new --config option to support a JSON config file. Luckily she agreed, so I got started right away.

I also received an issue and pull request to my repo. I had a lot of great discussion with Francesco and he mentioned that he was "really seeing the benefit of code review now" after I tested his changes and made several suggestions. I was able to test his code by adding his repo as a remote to my local repo and creating a tracking branch. After going back and forth a few times and fixing all issues, I was successfully able to merge Francesco's branch with my main branch.

I've been working on a static site generator called Jellybean over the past few weeks and this week, I wanted to add a few more features:

For this lab, I decided to contribute to Leyang Yu project, Jellybean SSG, . He is also using JavaScript so I decided that it would be a good idea to try adding to his project, so I filled and Issue Issue #6.

Similarly, Gustavo created an issue, added markdown support, and created a pull request for my repo. I provided some comments.