# Contributing to webpack-dev-server Do you use webpack-dev-server and want to help us out? Thanks! Please review this document before contributing. Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should show respect in addressing your issue or assessing patches and features. ## Core Ideas - There are hooks to add your own features, so we should not add less-common features. - The workflow should be to start webpack-dev-server as a separate process, next to the "normal" server and to request the script from this server or to proxy from dev-server to "normal" server (because webpack blocks the event queue too much while compiling which can affect "normal" server). - A user should not try to implement stuff that accesses the webpack filesystem. This leads to bugs (the middleware does it while blocking requests until the compilation has finished, the blocking is important). - It should be a development only tool. Compiling in production is bad, one should precompile and deliver the compiled assets. - Processing options and stats display is delegated to webpack, so webpack-dev-server/middleware should not do much with it. This also helps us to keep up-to-date with webpack updates. - The communication library (`SockJS`) should not be exposed to the user. ## Submitting a Pull Request - Good pull requests, such as patches, improvements, and new features, are a fantastic help. They should remain focused in scope and not contain unrelated commits. - It is advised to first create an issue (if there is not one already) before making a pull request. This way the maintainers can first discuss with you if they agree and it also helps with providing some context. - Run the relevant [examples](https://github.com/webpack/webpack-dev-server/tree/master/examples) to see if all functionality still works. When introducing new functionality, also add an example. This helps the maintainers to understand it and check if it still works. - Write tests. - Follow the existing coding style. - Make sure your PR's description contains GitHub's special keyword references that automatically close the related issue when the PR is merged. ([More info](https://github.com/blog/1506-closing-issues-via-pull-requests)) ## Setting Up a Local Copy 1. Clone the repo with `git clone https://github.com/webpack/webpack-dev-server`. 2. Run `npm install` in the root `webpack-dev-server` folder. 3. Run `npm link && npm link webpack-dev-server` to link the current project to `node_modules`. Once it is done, you can modify any file locally. In the `examples/` directory you'll find a lot of examples with instructions on how to run them. This can be very handy when testing if your code works. If you are modifying a file in the `client/` directory, be sure to run `npm run build:client` after it. This will recompile the files. ## Commit message Our commit messages format follows the [angular.js commits format](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits). We don't use the scope. The template of a commit would look like this: ### Commit Message Format Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type** and a **subject**: ``` :