Adding features to my open source project

Project Repo

Node-TILify

Issues

Exit program with proper exit codes #8
Add horizontal rule parsing from md to html #11

Merge Commits

Issue #8 - 80ccd5b
Issue #11 - cd87b5c

Changes made for new features

Issue #8

I had to make sure that if a program exits with an error, it should exit with -1 or 0 in case of a normal exit. This was to be implemented throughout the codebase.

if (args.length === 0) {
  console.log(
    'Please provide a command! Run the program with --help / -h for more information.'
  );
  process.exit(-1);
}

In the above code, when a user doesn't provide a command, I print the log on the console and exit code execution with -1 exit code.

else if (command === '-h' || command === '--help') {
  console.log(
    `This program is a Today I Learned tool where you pass a text file or directory of text files which converts them to HTML files.

    It has the following commands:
    -v, --version: Outputs the name of the program & version number.
    -h, --help: Outputs the help menu.
    -o, --output: The output directory (Optional).

    The files will be saved in './til' folder by default located in the current directory. 
    You can change the output folder by using -o or --output command.

    For example, to generate multiple HTML files from a directory with your preferred output directory run:
    node src/index.js ./path/to/directory -o ./path/to/output
    `
  );
  process.exit(0);
}

In the above code, when the user provides -h or --help command, the help log is printed to the console and the program is exited gracefully with 0 exit code.

Issue #11

I had to implement parsing --- into <hr> tags. This feature was rather simple implementation in terms of the code that I had to write however parsing 3 hyphens was somewhat difficult because a horizontal line has 4 different test cases:

---

There is a horizontal line below this paragraph
---

---
There is a horizontal line above this paragraph

There is a horizontal line below this paragraph
---
There is a horizontal line above this paragraph

The initial code that I wrote worked for some scenarios but not for others, which is when I took the approach of breaking down the problem into several parts and tackling the issue from there. I started writing code for 1st test case and kept on building on that code to tackle all of the test cases. The last test case where the horizontal line is between the 2 paragraphs was the trickiest one. Originally what happened is that the code wouldn't put the contents of the file in order as they appear, for example, <hr> tag would be placed before the <p> tag. As I tested the code I realized that every time I encounter ---, I should close all the open <p> tags and also deal with adding <hr> tag before I start iterating over the contents of the file again and that solved the problem.

Process of doing merges and working in parallel branches

I created 2 feature branches from the master branch to work on both issues. The idea of creating feature branches is to keep the code specific to an issue isolated into a branch and then once it's tested and good to merge, it can be merged back to the master branch and then pushed to remote which was the process that I followed when merging it back to local master and pushing to remote master. I didn't face any issues as far as merge conflicts are concerned considering I changed separate parts of the application for both issues.

Problems I faced

The only major problem that I faced was dealing with parsing --- into <hr> tags which I've explained above in the section titled Issue #11.

What I learnt

I learnt important git basics like creating a feature branch & merging code back to the master branch. This was a unique approach for me to merge 2 feature branches back into the master and push the latest local master code to the remote master.

What would I do differently

As I write a piece of code, I would thoroughly test the changes that I wrote instead of writing the entire code first and then testing it altogether since no code written in one go is always perfect code. There are always bugs in it and I realized it is always better to write small piece of code and test it before moving onto to writing more code.