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.
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.
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/masterinstead 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 rebaseinstead of
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.
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.