ModernSSG VS SSGNode

Well, I was impressed looking at docusaurus implementing so many features to their website. I wanted to work on Theme and Search Engine Optimization that required a lot of effort and knowledge. So, I started with some basic features that support my ModernSSG.

I have seen two other projects so far making an SSG. One of them was in a different language, so that explains how it would look different. The other one - in the same language I used, JS - had a different structure and implementation.

I have been working with open source development for four weeks now. It has been a great pleasure to work with GitHub. After completing pull requests to other developers. Now, I am moving forward to learn to merge changes from different branches. Here's my Swift development code Repo

https://github.com/japneetsingh035/ModernSSG/issues/16 https://github.com/japneetsingh035/ModernSSG/issues/15 https://github.com/japneetsingh035/ModernSSG/issues/17

PR

The formatting made the code hard to read. This was a big one for me, because I spend quite a bit of time making sure my own code is clean and easy to read. I filed an issue under his repo explaining my thoughts with an example of how to clean it up.

So far I have 3 "leftovers" in my issues. Sync/async, default paths (actually means I want to have the user input some options, or choose some things in the console. And for completing this issue I need to first complete the async one.) and yargs. Yargs is a more recent one, while also being an unattempted one so far. Looked doable. Note past tense in looked. It all went fine at first, I had examples to look at, I knew the steps to change my code. As it usually goes in programming fairy tales, everything was perfect until you had to run the code. I have managed to fix some things, but others I couldn't. What I noticed is the simplicity and stupidity of my mistakes, such as having a different variable name, or not including a file. Sure, some actually taught me things, such as using module.exports. The fact, however is - shit doesn't work.

At first I was lost in my task. I for sure read it wrong, since I have had a similar idea to implement way before this project - back in release 0.1. I wanted to change a default path for my input, since that was considered bad practice. But I still wanted to keep a default option, just for the sake of fast testing, instead of specifying a path every time. That's when the config idea came in. I tried to implement it back then, but I took on too many pieces - config, user input, async functions, error management... Yea, I got mostly stuck on user input which needed async stuff. I really struggle with async.

Language support

I started working on Alex's code. I found it clear with instructions on how to use node.js. I made the issue work by adding a feature to support markdown files to generate HTML files. Now, the original code forked to my Github account. I created the issue-8 branch and started working on developing the code to support MD files. I choose many features for Md files to support as ## heading ##, italics and bold. PR

We also had one where I couldn't launch my partner's code. I'm not sure what they did, but it got fixed. I have also asked my partner to fix some things I knew were problematic, but I didn't know how to do them myself. I had to add them as a collaborator so they can add their own branch. Had some readme issues, both of us

Git repository You can specify a file/folder to generate into valid html pages. They will appear in ./dist*. You can also change the styles.css to fit your preferences, it will get copied over to ./dist and will be applied to all webpages there. It also recognizes the first paragraph as a title.