diff --git a/.eslintrc.js b/.eslintrc.js index 1c1680b..d71bf15 100644 --- a/.eslintrc.js +++ b/.eslintrc.js @@ -5,7 +5,7 @@ module.exports = { browser: true, node: true, }, - extends: ['airbnb', 'plugin:import/recommended'], + extends: ['prettier', 'plugin:import/recommended'], parser: 'babel-eslint', parserOptions: { ecmaVersion: 7, diff --git a/.flowconfig b/.flowconfig index 0723008..d805bc0 100644 --- a/.flowconfig +++ b/.flowconfig @@ -1,6 +1,6 @@ [ignore] - .*/node_modules/fbjs/* +.*/node_modules/webpack-cli/* [libs] flow/interfaces diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md new file mode 100644 index 0000000..c1fa120 --- /dev/null +++ b/.github/CONTRIBUTING.md @@ -0,0 +1,188 @@ +# Contributing + +We would love for you to contribute and help make it even better +than it is today! As a contributor, here are the guidelines we would like you +to follow: + + - [Question or Problem?](#question) + - [Issues and Bugs](#issue) + - [Feature Requests](#feature) + - [Submission Guidelines](#submit) + - [Coding Rules](#rules) + - [Commit Message Guidelines](#commit) + +## Got a Question or Problem? + +Please, do not open issues for the general support questions as we want to keep GitHub issues for bug reports and feature requests. + +## Found an Issue? +If you find a bug in the source code or a mistake in the documentation, you can help us by +[submitting an issue](#submit-issue) to our [GitHub Repository][github]. Even better, you can +[submit a Pull Request](#submit-pr) with a fix. + +## Want a Feature? +You can *request* a new feature by [submitting an issue](#submit-issue) to our [GitHub +Repository][github]. If you would like to *implement* a new feature, please submit an issue with +a proposal for your work first, to be sure that we can use it. + +First open an issue and outline your proposal so that it can be +discussed. This will also allow us to better coordinate our efforts, prevent duplication of work, +and help you to craft the change so that it is successfully accepted into the project. + +**All features require a proper design and review by team members and product owners.** Before starting work, you might want to +discuss with us to figure out: + +* Is this something we want? +* What's the impact? + +Answering those questions first in the request might help us make a decision. + +## Submission Guidelines + +### Submitting an Issue + +Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you. + +We want to fix all the issues as soon as possible, but before fixing a bug we need to reproduce and confirm it. Having a reproducible +scenario gives us wealth of important information without going back & forth to you with additional questions. +If you can, please provide a repository with minimal reproduction steps. + +You can file new issues by filling out our [new issue form](https://github.com/oliviertassinari/serviceworker-webpack-plugin/issues/new). + + +### Submitting a Pull Request (PR) +Before you submit your Pull Request (PR) consider the following guidelines: + +* Search [GitHub](https://github.com/oliviertassinari/serviceworker-webpack-plugin/pulls) for an open or closed PR + that relates to your submission. You don't want to duplicate effort. +* Make your changes in a new git branch: + + ```shell + git checkout -b my-fix-branch master + ``` + +* Create your patch, **including appropriate test cases**. +* Run the full test suite, + and ensure that all tests pass. +* Commit your changes using a descriptive commit message that follows our + [commit message conventions](#commit). Adherence to these conventions + is necessary because release notes are automatically generated from these messages. + +* Push your branch to GitHub: + + ```shell + git push origin my-fix-branch + ``` + +* In GitHub, send a pull request to `serviceworker-webpack-plugin:master`. +* If we suggest changes then: + * Rebase your branch: + + ```shell + git rebase master -i + ``` + * Make the required updates. + * Re-run the test suites to ensure tests are still passing. + * Commit your changes. + * Force push to your GitHub repository (this will update your Pull Request): + + ```shell + git push -f + ``` + +That's it! Thank you for your contribution! + +#### After your pull request is merged + +After your pull request is merged, you can safely delete your branch and pull the changes +from the main (upstream) repository: + +* Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows: + + ```shell + git push origin --delete my-fix-branch + ``` + +* Check out the master branch: + + ```shell + git checkout master -f + ``` + +* Delete the local branch: + + ```shell + git branch -D my-fix-branch + ``` + +* Update your master with the latest upstream version: + + ```shell + git pull --ff upstream master + ``` + +## Coding Rules +To ensure consistency throughout the source code, keep these rules in mind as you are working: + +* All features or bug fixes **must be tested** by one or more specs (unit-tests or e2e-tests). + +## Commit Message Guidelines + +We have very precise rules over how our git commit messages can be formatted. This leads to **more +readable messages** that are easy to follow when looking through the **project history**. But also, +we use the git commit messages to **generate the change log**. + +### 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**, a **scope** and a **subject**: + +``` +(): + + + +