silkie VS mini-ssg

[metadata] name = silkie version = 1.0.7 ... description = Static site generator with the smoothness of silk long_description = file: README.md long_description_content_type = text/markdown url = https://github.com/oliver-pham/silkie project_urls = Bug Tracker = https://github.com/oliver-pham/silkie/issues classifiers = Programming Language :: Python :: 3 License :: OSI Approved :: MIT License Operating System :: OS Independent [options] packages = silkie python_requires = >=3.9 install_requires = click >= 8.0.0 markdown >= 3.3.0 yattag >= 1.14.0 python-frontmatter >= 1.0.0 [options.entry_points] console_scripts = silkie = silkie.cli:silkie

Last week, I already set up some automation tests for Silkie, my static site generator (SSG). Instead of running tests manually on each Pull Request (PR), I made an attempt to configure GitHub Actions to automate this Continuous Integration (CI) workflow. Moreover, I also helped my friend, Luke, add a test case to his SSG this week.

According to my parter's issue, I create a new test file named. I pull a new PR, the partner's Actions passed it. Before that, I found that many projects have the function of automatic error checking. I wonder how to do it. After lab9, I also created my own GitHub actions. I'm very excited.

After setting up static analysis tools last week, it's time to configure a testing framework for Continuous Integration (CI). There are several options for Silkie, my work-in-progress static site generator, but I decided to give Pytest a try. In this blog, I'll show you how I set up:

If you are tired of maintaining your coding style, I have good news for you. Fortunately, there are developer tools that can automate and streamline mundane development tasks. In this blog, I'll show you how I integrated 2 static code analysis tools and a package manager for pre-commit hooks into Silke, my work-in-progress static site generator.

After wandering the world of static site generators (SSG), I came across an eye-catching, well-documented, and developer-friendly one focusing on documentation sites: Docusaurus. After diving a bit deeper into their documentation, I realized they have many out-of-the-box features, which I can try integrating into Silke, an SSG I wrote from scratch.

This week, I noticed that some functions in my static site generator (SSG) were hardcoded with complex logic and "magic values", so I decided to focus on refactoring them. Without cleaning them up, maintaining them would be a tragedy. For instance, there was a function spanning 36 lines of code with 8 if/elif statements. Some of the statements even have nested if/elif statements themselves. You can find the function referenced in this issue.

This week on my Open Source journey, I attempted to add support for JSON formatted configuration files for an open source Static Site Generator (SSG). The owner of the repo, Tengzhen, also contributed the same feature to my SSG, Silkie. However, I made a step forward by testing his code from a tracking branch before merging it.

After establishing Markdown support for my static site generator (SSG), I decided to enable parsing Markdown horizontal rules along with HTML document language support. However, I developed the two features on separate branches this time, so I could switch between the two if I encountered any obstacle. Little did I know the obstacle was awaiting me at the end.

As for Eugene, he also contributed the same feature to Silkie, my SSG. I noticed his code might need to be fixed and refactored, so we worked together on both Slack and GitHub to resolve those issues. Given our time constraint and Eugene's lack of experience with Python, it was a success that we managed to add a new feature without breaking the existing ones.

#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).