We'd always love contributions to further improve the webpack ecosystem!
From opening a bug report to creating a pull request: every contribution is appreciated and welcome. If you're planning to implement a new feature or change the api please create an issue first. This way we can ensure that your precious work is not in vain.
Here are the guidelines we'd like you to follow:
Most of the time, if webpack is not working correctly for you, it is a simple configuration issue.
If you are still having difficulty after looking over your configuration carefully, please post a question to Discussions, StackOverflow with the webpack tag or ask this in our Discord. Questions that include your webpack.config.js, relevant files, and the full error message are more likely to receive responses. The issue tracker is for bug reports and feature discussions.
If you have discovered a bug or have a feature suggestion, please create an issue on GitHub.
Before you submit an issue, please search the issue tracker, an issue for your problem may already exist, and the discussion might inform you of workarounds readily available. We want to fix all the issues as soon as possible, but before fixing a bug, we need to reproduce and confirm it. If you have discovered a bug or have a feature suggestion, please use our issue template and provide a minimal reproduction scenario (GitHub repository or failed test case). Having a live, reproducible scenario gives us a wealth of important information without going back & forth to you with additional questions like:
- Version of Webpack used
- Webpack configuration(s)
- Version of loaders/plugins
- The use-case that fails
A minimal reproduce scenario allows us to quickly confirm a bug (or point out config problems) as well as confirm that we are fixing the right problem. We will be insisting on a minimal reproduction scenario in order to save the maintainers' time and ultimately be able to fix more bugs. We understand that sometimes it might be hard to extract essential bits of code from a larger codebase, but we really need to isolate the problem before we can fix it. Unfortunately, we are unable to investigate or fix bugs without a minimal reproduction, so if we don't hear back from you, we may have to close an issue that doesn't have enough info to be reproduced.
Do you want to fix an issue? Look at the issues with a tag of Send a PR. Here are some of the key labels/types you may encounter:
- bug: An unexpected problem or unintended behavior.
- enhancement: A suggestion for a new feature or improvement.
- question: Requests for clarification or more information.
- documentation: Issues related to improving or adding documentation.
Before you submit your Pull Request (PR) consider the following guidelines:
- Search GitHub for an open or closed issues/PRs related to your submission to avoid duplicating effort.
- Complete the
Pull Request Template. - Please sign the
Contributor License Agreement (CLA)when you open your pull request. We cannot accept your contribution without it. Be sure to sign using the primary email address associated with your local and GitHub account. - Recommended Commit your changes using a descriptive commit message that follows our commit message conventions.
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The header is mandatory and the scope of the header is optional.
Examples:
docs(readme): update install instructions
fix: refer to the `entrypoint` instead of the first `module`
If the commit reverts a previous commit, it should begin with revert:, followed by the header of the reverted commit.
In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.
Must be one of the following commit types:
- build: Changes that affect the build system or external dependencies (example scopes: babel, npm)
- chore: Changes that fall outside of build / docs that do not effect source code (example scopes: package, defaults)
- ci: Changes to our CI configuration files and scripts (example scopes: actions)
- docs: Documentation only changes (example scopes: readme, changelog)
- feat: A new feature
- fix: A bug fix
- perf: A code change that improves performance
- refactor: A code change that neither fixes a bug nor adds a feature
- revert: Used when reverting a committed change
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons)
- test: Addition of or updates to Jest tests
The scope is subjective & depends on the type see above. A good example of a scope would be a change to a particular class or module.
The subject contains a succinct description of the change:
- don't capitalize the first letter
- no dot (.) at the end
The body should include the motivation for the change and contrast it with previous behavior.
The footer should include any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.
Breaking Changes must start with the word BREAKING CHANGE: followed by a space or two new lines. The rest of the breaking change details should be provided after this.
Example
BREAKING CHANGE: Updates to `Chunk.mapModules`.
This release is not backwards compatible with `Webpack 5.x.x` due to breaking changes in webpack/webpack#4764
Migration: see webpack/webpack#5225
When submitting your contribution, a CLA (Contributor License Agreement) bot will verify whether you have signed the CLA. If it is your first time, it will link you to the right place to sign it. However, if the email used in your commits doesn’t match the email associated with your GitHub account, the CLA bot won’t accept your contribution.
Run git config user.email to see your Git email, and verify it with your GitHub email.
For your interest, time, understanding, and for following this simple guide.