Participating in Open Source

As I start my second week in OSD, I was tasked with creating a CLI tool for generating static sites and collaborating with my classmates in an open-source style.

Once I was done with the basic features of my tool, I posted my repo on Slack for potential partners to see. While I was waiting for someone to reach out to me, I tried reviewing some repos that interested me. In the process of reviewing, I found some issues and filed them.

Reviewing other people's code was somewhat of a challenge since you have to understand something that you did not write. I spent most of my time understanding the structure of the code. In the process, I found that there are two types of people when it comes to commenting: people like me who understand their code and think that there is no need for comments without thinking about other people understanding it, or people who leave comments on almost every line they have, which makes the code hard to read. From what I saw in myself and others, I came to a conclusion that there should be a balance of comments, and I need to read about this topic in order to improve.

I did a couple of reviews for different projects, and most of them required manual testing:

The first review was for this project til-tool. Something I found while testing was that this tool only looks for files within the current directory and it only accepts relative paths. I found this by coincidence because the text files I used to test the tool were on a different drive. The error gave me the issue that can be seen here:

D:\til-tool> ts-node src/index.ts -i D:\example 
Error: ENOENT: no such file or directory, scandir 'D:\til-tool\D:\example'
    at Object.readdirSync (node:fs:1452:3)
    at Object.module.exports.readDirectory (D:\til-tool\src\utility\readDirectory.ts:8:22)
    at Object.<anonymous> (D:\til-tool\src\index.ts:62:32)
    at Module._compile (node:internal/modules/cjs/loader:1254:14)
    at Module.m._compile (C:\Users\pavel\AppData\Roaming\npm\node_modules\ts-node\src\index.ts:1618:23)
    at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
    at Object.require.extensions.<computed> [as .ts] (C:\Users\pavel\AppData\Roaming\npm\node_modules\ts-node\src\index.ts:1621:12)
    at Module.load (node:internal/modules/cjs/loader:1117:32)
    at Function.Module._load (node:internal/modules/cjs/loader:958:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) {
  errno: -4058,
  syscall: 'scandir',
  code: 'ENOENT',
  path: 'D:\\til-tool\\D:\\example'

When reviewing my partner's repo, I found that the way he was creating a name for the HTML file was splicing the name on the first "." which made me think of a scenario where the user would have a file named like this: name.file.txt, which would result in the following output file name.html. I found it beneficial to only remove .txt, so I filed the following issue, and my partner fixed it.

One last issue I filed was for this project TxtToHTML. While testing the tool, I noticed that the tool would not empty the output file, resulting in a pile-up of files. So, I filed the following issue.

There was only one issue filed at the moment when I was writing this blog. In my installation instructions, I guided the user to use "npm i," but to run it, I included a method if the user had used "npm i -g." Yes, I was able to fix it by adding two methods for installation.

I learned that testing is super hard, and it's even harder to write code that is structured well enough for people to understand easily. I also learned that productivity can increase if project progression is broken down into stages.

Comments

[Mike Stemle]

What fun! Are you going to do Hacktoberfest?

[Pavel Belokon]

😊 yes I will, do you have any recommendation for repositories to contribute to ?

[Mike Stemle]

There are so many to choose from. If you’re really into typescript, I hear the Deno folks are looking for help, but there are also a lot of folks working on super-cool typescript projects.