Contributing Guidelines

Before submitting a bug or feature request

• Have you actually read the error message?
• Have you checked the Troubleshooting wiki?
• Have you searched for similar issues?
• Have you updated to the latest stable version of node, npm and the packages you're using?
• Have you checked that it's not a problem with one of the packages you're using, rather than npm itself?
• Have you looked at what's involved in fixing/implementing this yourself?

Capable programmers should always attempt to investigate and fix problems themselves before asking for others to help. Submit a pull request instead of an issue!

A great bug report contains

• Context – what were you trying to achieve?
• Detailed steps to reproduce the error from scratch. Try isolating the minimal amount of code needed to reproduce the error.
• A link to the full corresponding npm-debug.log output (e.g. as a gist).
• Evidence you've looked into solving the problem and ideally, a theory on the cause and a possible solution.

A great feature request contains

• The current situation.
• How and why the current situation is problematic.
• A detailed proposal or pull request that demonstrates how the problem could be solved.
• A use case – who needs this feature and why?
• Any caveats.

A great pull request contains

• Minimal changes. Only submit code relevant to the current issue. Other changes should go in new pull requests.
• Minimal commits. Please squash to a single commit before sending your pull request.
• No conflicts. Please rebase off the latest master before submitting.
• Code conforming to the existing conventions and formats. i.e. Please don't reformat whitespace.
• Passing tests in test/tap. Use existing tests as a reference.
• Relevant documentation.