Webpack version 4 support (#81)

* update for webpack 4
* update deps & webpack requirement
* chore: Make mocha throw on depreciation warnings
* chore: Add testcase on the contents of generatedd ServiceWorker
* chore: add github templates and community guidelines (#60)
* chore: Ensure proper error message when using swp with old version of webpack (#80)
* chore: Force travis to use node 8

.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,

.flowconfig

@@ -1,6 +1,6 @@
 [ignore]
-
 .*/node_modules/fbjs/*
+.*/node_modules/webpack-cli/*
 
 [libs]
 flow/interfaces

.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)
+
+## <a name="question"></a> 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. 
+
+## <a name="issue"></a> 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.
+
+## <a name="feature"></a> 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.
+
+## <a name="submit"></a> Submission Guidelines
+
+### <a name="submit-issue"></a> 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).
+
+
+### <a name="submit-pr"></a> 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
+    ```
+
+## <a name="rules"></a> 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).
+
+## <a name="commit"></a> 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**:
+
+```
+<type>(<scope>): <subject>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+The **header** is mandatory and the **scope** of the header is optional.
+
+Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
+to read on GitHub as well as in various git tools.
+
+### Revert
+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.
+
+### Type
+Must be one of the following:
+
+* **build**: Changes that affect the build system or external dependencies
+* **ci**: Changes to our CI configuration files and scripts
+* **docs**: Documentation only changes
+* **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
+* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
+  semi-colons, etc)
+* **test**: Adding missing tests or correcting existing tests
+
+### Scope
+The scope should be the name of the module affected as perceived by the person reading changelog generated from the commit messages.
+
+### Subject
+The subject contains succinct description of the change:
+
+* use the imperative, present tense: "change" not "changed" nor "changes"
+* don't capitalize first letter
+* no dot (.) at the end
+
+### Body
+Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
+The body should include the motivation for the change and contrast this with previous behavior.
+
+### Footer
+The footer should contain any information about **Breaking Changes** and is also the place to
+reference GitHub issues that this commit **Closes**.
+
+
+[GitHub]: https://github.com/oliviertassinari/serviceworker-webpack-plugin/issues

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,25 @@
+## Bug Report or Feature Request (mark with an `x`)
+```
+- [ ] bug report -> please search issues before submitting
+- [ ] feature request
+```
+
+## Versions.
+```
+browser:
+browser version: 
+operating system:
+webpack version:
+```
+
+
+## Repro steps.
+<!--Simple steps to reproduce this bug.-->
+
+## Desired or expected functionality
+<!--What would like to see implemented?
+What is the use case?-->
+
+
+### Mention any other details that might be useful.
+<!--include a link to a repository with minimal reproduction steps, gif, video or other assets that can help to fix this bug.-->

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,31 @@
+<!--
+There are two main goals in this document, depending on the nature of your PR:
+
+- description: please tell us about your PR
+- checklist: please review the checklist
+
+To help to quickly understand the nature of your pull request,
+please create a description that incorporates the following elements:
+-->
+
+### What is accomplished by your PR?
+description...
+
+### Is there something controversial in your PR?
+please take a moment to tell us about your choices...
+
+
+### Link to the Issue
+or a link to a ticket system...
+
+# Checklist
+
+### New Feature / Bug Fix
+
+- [ ] Run unit tests to ensure all existing tests are still passing
+- [ ] Add new passing unit tests to cover the code introduced by your PR
+
+
+<!--
+Thanks for contributing!
+-->

.gitignore

@@ -1,5 +1,5 @@
 *.log
-/node_modules
+node_modules
 /lib
 /docs/dist
 .idea/

.travis.yml

@@ -1,6 +1,6 @@
 language: node_js
 node_js:
-  - stable
+  - 8
 sudo: false
 cache:
   directories:

CODE_OF_CONDUCT.md

@@ -0,0 +1,46 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [email protected]. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2017 Olivier Tassinari
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

README.md

@@ -92,6 +92,8 @@ It's taking a `serviceWorkerOption` argument and must return a promise.
 - `transformOptions`, *function*:
 This callback function receives a raw `serviceWorkerOption` argument.
 The `jsonStats` key contains all the webpack build information.
+- `minimize`:
+Whether to minimize output. Defaults to `process.env.NODE_ENV === 'production'`
 
 ### `runtime(options)`
 

docs/src/Body.js

@@ -1,6 +1,7 @@
 // @flow weak
 
-import React, { PropTypes } from 'react'
+import React from 'react'
+import PropTypes from 'prop-types'
 
 const styles = {
   root: {

docs/src/Footer.js

@@ -1,6 +1,7 @@
 // @flow weak
 
-import React, { PropTypes } from 'react'
+import React from 'react'
+import PropTypes from 'prop-types'
 
 const Footer = props => {
   const { maintainerName, maintainerUrl, repositoryName, repositoryUrl } = props

docs/src/Head.js

@@ -1,6 +1,7 @@
 // @flow weak
 
-import React, { PropTypes } from 'react'
+import React from 'react'
+import PropTypes from 'prop-types'
 
 const Head = props => {
   const { children, description, name } = props

docs/src/app.js

@@ -6,4 +6,5 @@ import Main from './Main'
 import './normalize.scss'
 import './stylesheet.scss'
 
+// $FlowFixMe
 render(<Main />, document.querySelector('#main'))