Begin with..

This lab 4 is a new device to be added to ssg. Instead of entering and executing a command for each desired function, if you enter -c or --config config.json using the config.json file, the It should be executed based on the command and the value of the command, and I was assigned a requirement to work in the ssg of another student, not my ssg.

Working with who..

Actually, I already felt tired of entering each command separately every time I run ssg, and personally I was thinking similar to lab4, so I really liked this requirement and felt good. Unfortunately, it was a collaboration with a student other than my code, so while I was looking for a suitable collaborator, a student named Hung Nguyen wanted to collaborate with me, so I decided to work together.

Started..

Hung Nguyen's code was similar to mine in many ways, so it was fortunately very easy to work with. However, personally, I think he would have been able to manage ssg more conveniently and efficiently if he divided the file into 2 or 3 parts instead of putting everything in one JavaScript file.

What I did..

The first touch on his code was to update yargs so that the api recognizes the config options.

.option("config", {
        alias: "c",
        desc: "Add an option flag to indicates the config for replacing using command line argument. e.g: --config ./ssg-config.json means using ./ssg-config.json's values for command line argument."
    })

After that, when -c or --config is entered on the command line, the authentication process and the value in config.json after authentication are assigned to the required command line input value of each function.

let fileOrDir;
let outputDir;
let lang;
let css;
if(command.c || command.config){
    //check if the file is json
    if(!command.c.endsWith("json") || !command.config.endsWith("json")){
        return console.log("Sorry your input file is not json type.")
    }
    const jsonData = require(`../${command.c}`);
    console.log(jsonData);
    fileOrDir = jsonData.input;
    outputDir = (jsonData.output && jsonData.output.replace('./', '')) ?? 'dist';
    lang = jsonData.lang;
    css = jsonData.styleSheet;
    //ignore all options
    if(!fileOrDir){
        console.log('Please provide -c or -i options');
    }
}else {
    fileOrDir = takeFile();
}

After completing minor modifications, Hung's ssg has successfully recognized config.json.

Pullrequest and small trouble...

When everything was finished and I finally proceeded to the pull request, something embarrassing happened. One of the students requested a pull request that added the config function to Hung's ssg arbitrarily, even though I showed that I was collaborating with the friend by making an issue first without any understanding or question. This was very rude and rude behavior that went without discussion (I think so) and I immediately reported the matter to Hung and fortunately he got my pull request. Personally, I don't want someone to be rude like that and it's not common in the development industry. Because his indifference behavior can be an act of trampling on other people's time and effort.
( -᷅_-᷄)

And after that

After everything was resolved, I also received a pull request from Hung, and after checking the integrity of the code, I successfully merged it. His code also worked well and I'm happy with it. The pre-merger collision test proposed in lab4 is new, so it is a little slow to learn, and it seems it will take some time to get used to it.

As a result

From this lab4 I had a nice experience again with the collaborator, which also improved my eyes to see the other's code. However, the issue that someone tried to interrupt my code is really not a fun experience. I hope will not have the same situation twice... (-`д´-)