Contributing to open source project – npm mysql packages.json

I chose the npm mysql package to contribute to. In this post, I will go over the steps I took for contributing a minor fix to an open source project, using a Linux terminal, Vi editor and Git.

Review Process

Looking at the package.json file, I noticed that the repository field URL did not contain an absolute URL path.  So I ran the file through the package-json-validator:


The validator also recommends to include the “keywords” and “bugs” fields.  I read over the official npm documentation to see how to properly write these fields in package.json.


"repository" :
  { "type" : "git",
    "url" : ""

Keywords: An array of strings to help developers find the package using ‘npm search’.


  "url" : "",
  "email" : ""

I can adjust the fields now to match these formats.

Adding my changes

  • Fork repository from
  • Clone project to my local workspace: git clone
  • I used Vim editor to edit the package.json file: vi packages.json
  • Adjust repository URL to:
    "repository": {
      "type": "git",
      "url": ""
  • Add change to git staging: git add package.json
  • I thought it might be a good idea to keep this change separate from the “keywords + bugs” fields change for the sake of having separate commit messages for each, so I committed this change first: git commit -m "replaced repository url with valid repository url and type"

  • Then back to editing package.json in vi to add the “keywords” and “bugs” fields:
"keywords": [
"bugs": "",

Since I only included the issues URL in the bugs field, I followed the suggestion in npm of having it as only a single string instead of an object.

  • Add change: git add package.json
  • Commit change: git commit -m "added keywords + bugs url"
  • View changes in commits before pushing to repo: git show

After running git show, I noticed the indentation was off (4 spaces instead of 2) on the “sql” keyword line.  I had already set my tabwidth setting to 2, but found out that this setting does not insert spaces in replacement of a tab character. To do this you have to set the shiftwidth and set expandtab. So I added these two lines to my ~/.vimrc file (as root user, or in Fedora /etc/vimrc):

:set shiftwidth=2
:set expandtab

I switched back to my regular user and opened the package.json file again in vi.  If I press enter now from the “mysql” line, vi now automatically inserts 2 spaces at the beginning of the line.  To double check this, after hitting enter you can backspace and notice the cursor now moves back one space instead of the tabwidth’s set number of spaces.

An alternate quick fix for this of course would be to use a regular expression substitution in vi on lines 13 to 23:

:13,23s/\t/  /g

This will replace all tab characters with two spaces from lines 13 to 23.

Continuing with my changes… now I save these changes and exit vi CTRL + ZZ

  • See if changes are correct: git diff package.json
  • Spaces look good now, so I can add my changes: git add package.json
  • Commit changes to git: git commit -m "fixed vi indent to 2 spaces for sql keyword"

Now looking at the last three commits I made, I figured since the latest commit was only a minor fix to the previous, I wanted to have the two as only one commit.

git log --max-count 3


You can do this with a “git rebase”:

git rebase --interactive HEAD~2

This opens the git rebase file:


Here I want to pick the “added keywords + bugs url” as the main commit, and squash the “fixed vi indent…” commit into the main commit.


Now I can hit Shift + ZZ to save my changes and exit git rebase.

Git now displays the combination of commit messages:


Since I want to only use the “added keywords + bugs url” commit message, I can delete the 2nd commit message.


Hit Shift + ZZ again to save the changes and exit.

Now the “fixed vi indent…” commit has been squashed with the “added keywords + bugs url” commit as one commit.


Now I can push to the remote repository:
git push

One thing to note, as mentioned in github regarding git rebase, if the commits you squashed locally were previously already pushed to your remote repository, you would have to run:

git push origin branch-name --force

Although you have to be careful when choosing to do a rebase on already pushed commits and make sure they have not been reviewed or used in any way.  Use –force only only for very recent commits.

Creating Pull Request

Create the pull request by clicking the ‘Create pull request’ button in GitHub, then write a description of the changes you’ve made and create the new pull request.


Pull Request Review

One of the collaborators were quick to respond within 3 minutes of the pull request.  It was noted that npm automatically populates these fields now so adjusting the packages.json file is not necessary.  The new npm also no longer uses the keywords array in the search and the validator URL is also valid as a shortcut URL for git.

So I ended up creating a new issue for the validator-tool and the maintainer confirmed that the validator is slightly outdated and said they would be looking into updating it when they had the chance.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s