Becoming a First Time Contributor in Node.js

Recently I made my first contribution to Node.js and decided to write this post as a means of sharing what I learned and, potentially, helping others interested in getting started.

First you’re going to want to view this guide. It is made for first time contributors to the project and should help a lot. This blog post will be going over things I struggled with or discovered that the guide itself didn’t itself mention/cover.

Set Up

The thing that separated Node.js from other projects I contributed before was that it was much, much bigger. A behemoth. The amount of files alone eclipsed the previous project I worked on. But the thing that made it intimidating wasn’t so much the loc or the amount of files it had; it was the build time.

When I first ran make test (the command to run tests for the application), it took approximately 30 minutes before any tests were actually started. It turns out the project was being built beforehand, which was why the command was taking so long.

As the project was built and it was displaying output to the console, I didn’t understand anything that was being displayed. Worse yet I would get all sorts of warnings. I thought I was doing something wrong at first, that maybe the program was looping and I messed up the configuration of the project somehow.

But after some waiting everything seemed to build and work fine, it just took a while for it to be completed.

Documentation

Be sure to read this and this guide before doing any work, before you even attempt to make a new branch or merge any upstream changes. Below some of the more notable things that popped out to me while I read them myself:

• When merging upstream changes to master you’re going to want to run git merge --ff-only upstream/master instead of git merge upstream/master, like you may see in other projects
• Commits have strict naming conventions. For example if you’re changing the implementation in a test, your commit will need to be prefaced with test: and every word will need to be lowercase except for pronouns, acronyms and words that refer to code
• After you commit your changes and want to sync with the upstream repo, run git rebase instead of git merge

One of the great things about Node is the documentation; it’s very comprehensive and well laid out. However that also means there are many strict rules that need to be met, so it’s important to read about them before starting any work.

Other Observations

A lot of the fixes I’ll see for the project aren’t necessarily that complicated, they’ll be just one or two lines, small corrections. So if you want to contribute to Node I don’t think you’d have to add anything too difficult or comprehensive.

When you make your PR a new CI build will be run. Note that if the build fails it might not be your fault, one of the maintainers might end up re-running the build and fixing it.