Miroslav Bajtoš edited this page Apr 22, 2014 · 6 revisions

Getting your code into Node Inspector

The only "official" Node Inspector repository is For code, docs, tests, or anything else, node-inspector/node-inspector is the repository where all patches have to end up if they are going to be in the release. To submit a patch fork the repository and send a pull request via github to node-inspector/node-inspector.

Some participation guidelines

  • Miguel de Icaza has a good post on Open Source Contribution Etiquette that is worth reading, as the guidance he gives applies well to Node Inspector.
  • Create a github issue for large changes and discuss the change there before coding
  • Javascript code style should follow Google's JavaScript style guide and be run through the linter. npm run lint to validate, you need to have GJsLint installed.


Node Inspector comes with an automated test suite run via "npm test". The tests are written in BDD style using mocha and chai.

Git commits/patches

Commit messages should follow follow 50/72 format, i.e.

  • First line is 50 characters or less and summarises the commit
  • Then a blank line
  • Remaining text should be wrapped at 72 characters and provide longer/additional information.

Commits must have the author field properly filled out with your name and email address.

Use GitHub Flow for your work on Node Inspector:

  1. Clone the git repository.
  2. Create a branch for you change/feature off of the master branch.
  3. Make your change. Remember to update tests as well as code!
  4. Commit your change and push it to github.
  5. Use github's pull requests to submit the patch.

Addressing code review issues

Once you have submitted a pull request, Node Inspector maintainers will review the changes. More often than not, some of your code needs to be improved before the patch is accepted.

You don't have to create a new pull request to update your patch. Simply add more commits to your branch, github will automatically add them to the pull request. This way it's also easier to know what has been changed from the last review, which makes the life of maintainers much easier.

When all issues are resolved and the code is good to merge, you can squash the commits to keep the history concise. Google for git rebase interactive to learn how to clean up your git history.

Note that after the history was rewritten, git push will be rejected by the git server. Don't worry about that, just tell git to push it anyway: git push -f.