All interactions in the npm organization on GitHub are considered to be covered by our standard Code of Conduct.
When submitting a new bug report, please first search for an existing or similar report & then use one of our existing issue templates if you believe you've come across a unique problem. Duplicate issues, or issues that don't use one of our templates may get closed without a response.
1. Clone this repository...
$ git clone git@github.com:npm/cli.git npm
2. Navigate into project & install development-specific dependencies...
$ cd ./npm && node . install
3. Write some code &/or add some tests...
...
4. Run tests & ensure they pass...
$ node . run test
5. Open a Pull Request for your work & become the newest contributor to npm
! 🎉
We use Conventional Commits. When opening a pull request, please be sure that either the pull request title, or each commit in the pull request, has one of the following prefixes:
feat
: For when introducing a new feature. The result will be a new semver minor version of the package when it is next published.fix
: For bug fixes. The result will be a new semver patch version of the package when it is next published.docs
: For documentation updates. The result will be a new semver patch version of the package when it is next published.chore
: For changes that do not affect the published module. Often these are changes to tests. The result will be no change to the version of the package when it is next published (as the commit does not affect the published version).
We use tap
for testing & expect that every new feature or bug fix comes with corresponding tests that validate the solutions. Tap also reports on code coverage and it will fail if that drops below 100%.
We've set up an automated benchmark integration that will run against all Pull Requests; Posting back a comment with the results of the run.
Example:
You can learn more about this tool, including how to run & configure it manually, here
It should be noted that our team does not accept third-party dependency updates/PRs. We have a release process that includes checks to ensure dependencies are staying up-to-date & will ship security patches for CVEs as they occur. If you submit a PR trying to update our dependencies we will close it with or without a reference to these contribution guidelines.
Our core team is responsible for the maintenance of the tooling/automation in this project & we ask collaborators to kindly not make changes to these when contributing (ex. .github/*
, .eslintrc.json
, .licensee.json
etc.)