Contributing to Verdaccio
We are happy that you wish to contribute to this project. For that reason, we present you with this guide.
Additional information is available on the wiki.
- How Do I Contribute?
- Reporting Bugs
- Request Features
- Update Tests
- Develop Plugins
How Do I Contribute?
There are different ways to contribute, each with a different level of involvement and technical knowledge required, such as:
Please read this document carefully. It will help maintainers and readers in solving your issue(s), evaluating your feature request, etc.
Development guides can be found on the wiki:
We welcome clear, detailed bug reports.
Bugs are considered features that are not working as described in documentation.
If you've found a bug in Verdaccio that isn't a security risk, please file a report in our issue tracker.
NOTE: Verdaccio still does not support all npm commands. Some were not considered important and others have not been requested yet.
Search to see if it has already been reported via the issue search.
Additionally, we have labelled questions for easy follow-up as questions.
If so, up-vote it (using GitHub reactions) or add additional helpful details to the existing issue to show that it's affecting multiple people.
Check Website For Solution
Some of the most popular topics can be found in our website(http://www.verdaccio.org/docs/en/installation.html)
Questions can be asked via Discord
Please use the
Check If It's Been Fixed
Check if the issue has been fixed — try to reproduce it using the latest
master or development branch in the repository.
New feature requests are welcome. Analyse whether the idea fits within scope of the project. Then, detail your request, ensuring context and use case is provided.
- A detailed description the advantages of your request
- Whether or not it's compatible with
- A potential implementation or design
- Whatever else you have in your mind
Submitting a Pull Request
The following are the steps you should follow when creating a pull request. Subsequent pull requests only need to follow step 3 and beyond.
- Fork the repository on GitHub
- Clone the forked repository to your machine
- Make your changes and commit them to your local repository
- Rebase and push your commits to your GitHub remote fork/repository
- Issue a Pull Request to the official repository
- Your Pull Request is reviewed by a committer and merged into the repository
NOTE: While there are other ways to accomplish the steps using other tools,
the examples here will assume most actions will be performed via
Make Changes and Commit
Before committing, you must ensure there are no linting errors and all tests pass.
To do this, run all tests (including e2e):
Then, and only then, you can create your pull request.
We follow the conventional commit messages convention in order to automate CHANGELOG generation and to automate semantic versioning.
feat: A new feature
fix: A bug fix
A commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in semantic versioning).
A commit of the type fix patches a bug in your codebase (this correlates with PATCH in semantic versioning).
Commits types such as as
chore: are valid but have no effect on versioning. It would be great
if you use them.
npm run commitmsg to check your commit message format.
PRs that do not follow the commit message guidelines will not be merged.
Any change in source code must include test updates.
If you need help with how testing works, please refer to the following guide.
If you are introducing new features, you MUST include new tests. PRs for features without tests will not be merged.
Things excluded from tests:
- Flow types
Plugins are add-ons that extend the functionality of the application.
If you want to develop your own plugin: