Skip to content
This repository has been archived by the owner on Nov 20, 2019. It is now read-only.

Webpack version 4 support #81

Merged
merged 19 commits into from
Jul 23, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .eslintrc.js
Original file line number Diff line number Diff line change
Expand Up @@ -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,
Expand Down
2 changes: 1 addition & 1 deletion .flowconfig
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[ignore]

.*/node_modules/fbjs/*
.*/node_modules/webpack-cli/*

[libs]
flow/interfaces
Expand Down
188 changes: 188 additions & 0 deletions .github/CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -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
25 changes: 25 additions & 0 deletions .github/ISSUE_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -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.-->
31 changes: 31 additions & 0 deletions .github/PULL_REQUEST_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -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!
-->
2 changes: 1 addition & 1 deletion .gitignore
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
*.log
/node_modules
node_modules
/lib
/docs/dist
.idea/
Expand Down
2 changes: 1 addition & 1 deletion .travis.yml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
language: node_js
node_js:
- stable
- 8
sudo: false
cache:
directories:
Expand Down
46 changes: 46 additions & 0 deletions CODE_OF_CONDUCT.md
Original file line number Diff line number Diff line change
@@ -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 olivier.tassinari@gmail.com. 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/
21 changes: 21 additions & 0 deletions LICENSE
Original file line number Diff line number Diff line change
@@ -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.
2 changes: 2 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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)`

Expand Down
3 changes: 2 additions & 1 deletion docs/src/Body.js
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
// @flow weak

import React, { PropTypes } from 'react'
import React from 'react'
import PropTypes from 'prop-types'

const styles = {
root: {
Expand Down
3 changes: 2 additions & 1 deletion docs/src/Footer.js
Original file line number Diff line number Diff line change
@@ -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
Expand Down
3 changes: 2 additions & 1 deletion docs/src/Head.js
Original file line number Diff line number Diff line change
@@ -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
Expand Down
1 change: 1 addition & 0 deletions docs/src/app.js
Original file line number Diff line number Diff line change
Expand Up @@ -6,4 +6,5 @@ import Main from './Main'
import './normalize.scss'
import './stylesheet.scss'

// $FlowFixMe
render(<Main />, document.querySelector('#main'))
Loading