FilerJS – 1st Open-Source Project Release

When I first started open-source I was saying to myself that I probably will not find a single bug in an open-source project. This is probably because I was not confident at first as I taught that maybe I am not the best programmer. Like I was always taught, it is easier to give up and not try. I was always told you have to try and you have to take risks in life, otherwise you won’t be able to achieve the goal you are striving for. In the open-source world you have to be brave and take the risks. Even if something does not work out, you can always get positive constructive feedback and help from fellow programmers. My philosophy is that the best way to become more comfortable with open-source technology is to get out there and try the best you can, that is the only way you become a more better and confident open-source programmer.

What is FilerJS?
Filer is a POSIX-like file system interface for node.js and browser-based JavaScript, as mentioned from the filerjs GitHub site. In other words, POSIX is a file system that works in browsers that run in JavaScript, like the  Javascript framework that we used in the project called NodeJS. It is compatible with the following providers: node.js: v0.10.*+, IE: 10+ (IndexedDB), Firefox: 26+ (IndexedDB), Chrome: 31+ (IndexedDB, WebSQL), Safari: 7.0+ (WebSQL), Opera: 19+ (IndexedDB, WebSQL), iOS: 3.2+ (WebSQL), Android Browser: 2.1-4.4 (WebSQL), and 4.4+ (IndexedDB). Anyways, I have given a short introduction to filerJS. Now I will explain the process I went through to file a bug.

Step 1: First things first, I looked into the filerjs git repository and forked the whole repository into my GitHub Account. I had to click the fork in the top right of the filerjs git repository.

Step 2: Next I also cloned the repository, using a git command in Bash, and then I opened the filerjs code in VSCode.

Step 3: I then installed some dependencies, like npm install karma

Step 4: After that, I ran npm test command. But, I later learned that I could run the npm test:manual and test filer in the browser by going to the localhost provided by the npm test. I opened up the mozilla console and I got the message that the fs.exists method is deprecated, which means that the fs.exists method does not follow the standard format for how node callbacks are supposed to work. By the way that is not the problem I was fixing. I will get to it now. The day before, Robert suggested implementing filer coverage and included an explanation link for filer coverage. The next day, Dave says that it would be cool to implement that idea. I decided to file an issue on implementing karma coverage, for which Dave gave me the green light.

Here is a screenshot of that:

Screenshot (6)
My first Issue

I filed this issue because Robert noticed that there was no code coverage for the filerjs code. So, I looked into Karma-Coverage which was very interesting. For those who are new to Karma-Coverage, it is a development dependency that allows to add coverage for code.

Step 5: I started working on this issue and the first thing I did, was install the dev dependency by running this command:

npm install karma karma-coverage –save-dev

Then, I installed Istanbul by running the command:

npm install -g istanbul

After that, I ran this command to test for coverage:

istanbul cover test.js

Screenshot (7)
istanbul cover command

Dave later told me that instead of running istanbul, to let karma run it as a plugin and he suggested to go to this link: and to specify a coverage reporter.

Step 6:  I went into filerjs and modified the karma.conf.js and package.json files, to have karma-coverage. The only thing I did not implement was coverage for each of the test files. I just installed the dependencies, updated the files and tested everything generally.

Step 7: After creating the changes, I made a new branch with my issue number to store all my changes there. Next, I executed the git add, git commit -m and git push commands to add all my changes to the branch I created.

Step 8:  Next I went into the filerjs repository, clicked on the pull requests tab, then selected new pull request and from there I added all my specifications and code changes.

Step 9: The final step was to select create pull request. The pull request was not fully completed because I was monitoring my pull request to see if anyone commented, but I did not see any comments because I did not do too much to the code that could have been checked.

Here is the image of the pull request and images of the files I have modified:

Screenshot (10)
My pull Request


Screenshot (14)
karma.conf.js File


Screenshot (15)
package.json File


Screenshot (16)
Coverage file generated by running the npm install istanbul command

My conclusion from the project

As a result, these were the steps I took to file my pull request. I learned many things from doing all this, and the main thing I learned is that it does not matter how weak or strong of a programmer you are, you cannot give up. If you take part in open-source often, it will become easier for you to find bugs  and to participate in finding bugs with the community. For next time, I want to of course fix my problems to their fullest because my pull request was not completed in the fullest.

The pull request I helped fixed was this:

Screenshot (12)
PR, I helped with

The issue that I noticed in the pull request was that the author used var fs = util.fs, instead of var fsPromises = util.fs().promises. I asked him if he could make the changes because I noticed that in most peoples test code they all did it the way. That is why I suggested this to the author of this pull request.  The code looks more shortened that way, and it follows the format everyone wrote the promise code in. As a result, it made it look as if one person wrote all the test code for filerjs. The author took my advice and here is how his code looked like at the end:

Screenshot (13)
Final Version of Code

Once, again excellent job for the student that filed this pull request. Good Job!

Conclusions from helping the person

I felt really good for helping others because one, I took part in open-source for my first-time ever and two, I felt as if I was doing something very optimistic. As a result, both the author and I, were happy that we solved the issue very optimistically.

Ultimate Conclusion

I had tons of fun doing this and I am vey excited for the next project. My advice to anyone reading this blog is that do not be scared to dive into open-source. If you stay out of open-source you will not learn how to do excellent work in open-source. I was scared myself, but as you see I filed my first bug. You will feel very good after and you will get nice feedback from GitHub when you file your first issue. Here was the feedback I received:

Screenshot (17)
Thank you everyone for reading this blogpost and Have Fun Coding!
– Mark Krutik

References, my issues, my pull requests, a persons pull requests I edited and the persons pull requests I edited:

  1. The pull request of the person I helped:
  2. The issue of the person I helped
  3. My pull request:
  4. My issue:
  5. FilerJs Info I used for this blog and PR:
  6. Karma-Coverage Reference:
  7. Istanbul Reference:
  8. Setting up karma example: