Add webpack configurator tools #20

zetlen · 2018-03-12T14:48:03Z

MAGETWO-88298 Demo of PWA development workflow (continued)
- MAGETWO-88757 Achieve 90% test coverage
- MAGETWO-88758 Full documentation and links to README

Adds two important utilities for development. Excerpted from READMEs:

ServiceWorkerPlugin

Webpack plugin for configuring a ServiceWorker for different PWA development
scenarios.
           new ServiceWorkerPlugin({
               env: {
                   mode: 'development'
               },

               paths: {
                   output: path.resolve(__dirname, 'web/js'),
                   assets: path.resolve(__dirname, 'web')
               },
               enableServiceWorkerDebugging: true,
               serviceWorkerFileName: 'sw.js',
               runtimeCacheAssetPath: 'https://cdn.url'
           })
Purpose

This plugin is a wrapper around the Google Workbox Webpack Plugin,
which generates a caching ServiceWorker based on assets emitted by Webpack.

In development, ServiceWorkers can cache assets in a way that interferes with
real-time editing and changes. This plugin takes configuration that can switch
between "normal development mode", where ServiceWorker is disabled, to "service
worker debugging mode", where ServiceWorker is enabled and hot-reloading.

Notes

MAGETWO-88754 Auto-disable service worker in dev mode
Did not end up having to fork Workbox, though we reserve the right in the future.
TODO: add automatic unregistration of SW
TODO: add default config values
TODO: make runtime caching optional

PWADevServer

Utility for configuring a development OS and a webpack-dev-server for PWA
development.

Usage
{
   devServer: await PWADevServer.configure({
          publicPath: '/pub/static/frontend/Vendor/theme/en_US/',
           backendDomain: 'https://magento2.localdomain',
           serviceWorkerFileName: 'sw.js',
           paths: {
               output: path.resolve(__dirname, 'web/js'),
               assets: path.resolve(__dirname, 'web')
           },
           id: 'magento-venia'
       })
}    
Purpose

The typical Webpack local development scenario uses the devServer settings in
webpack.config.js to create
a temporary local HTTP server for showing edits in real time.

PWA development has a couple of particular needs:

The host must be secure and trusted to allow ServiceWorker operation

The host must be unique to prevent ServiceWorker collisions

Furthermore, Magento PWAs are Magento 2 themes running on Magento 2 stores, so
they need to proxy backend requests to the backing store in a customized way.

Notes

TODO: consolidate configuration
TODO: confirm Windows support
TODO: add default config values
TODO: add Firefox support

MagentoResolver

Adapter for configuring Webpack to resolve assets according to Magento PWA conventions.
       resolve: await MagentoResolver.configure({
           paths: {
               root: __dirname
           }
       })
Purpose

Generates a configuration for use in the resolve property of Webpack config.
Describes how to traverse the filesystem structure for assets required in source
files.

Currently, MagentoResolver does very little, but it's likely that the Magento
development environment will require custom resolution rules in the future; this
utility sets the precedent of the API for delivering those rules.

I added a lot of utilities and dependencies, and I'm sorry that this PR is so large as a consequence. This is part of a larger branch and the purpose of most of the separate utilities will become clear later.

jcalcaben · 2018-03-14T19:55:38Z

docs/MagentoResolver.md

@@ -0,0 +1,56 @@
+## MagentoResolver
+
+Adapter for configuring Webpack to resolve assets according to Magento PWA conventions.


Suggest rewording to:

An adapter that configures Webpack to resolve assets according to Magento PWA conventions.

Is there documentation for the Magento PWA conventions? If so, we should link to it.

jcalcaben · 2018-03-14T20:23:03Z

docs/MagentoResolver.md

+   config that uses it must use the [Exporting a Promise configuration type](https://webpack.js.org/configuration/configuration-types/#exporting-a-promise).
+   The newer `async/await` syntax looks cleaner than using Promises directly.
+
+### Purpose


I propose moving this section above Usage to make the information flow better: conceptual -> example -> API reference

jcalcaben · 2018-03-14T21:36:50Z

docs/MagentoResolver.md

+```
+
+
+ - ⚠️ `MagentoResolver.configure()` is async and returns a Promise, so a Webpack


Suggest rewording to:

ℹ️ Note: MagentoResolver.configure() is asynchronous and returns a Promise. For more information, see the Webpack documentation about Exporting a Promise configuration type.

In the example provided, the newer async/await syntax is used because it is a cleaner alternative to using Promises directly.

jcalcaben · 2018-03-14T21:42:31Z

docs/MagentoResolver.md

+
+### Purpose
+
+Generates a configuration for use in the [`resolve` property of Webpack config](https://webpack.js.org/configuration/resolve/).


Suggested rewording:

This class generates a configuration object for the resolve property of a Webpack config file. The configuration object describes how Webpack should traverse the filesystem structure to retrieve assets required in source files.

jcalcaben · 2018-03-14T21:46:42Z

docs/MagentoResolver.md

+
+### API
+
+`MagentoResolver` has only one method: `.configure(options)`. It returns a Promise


The information in this paragraph is already described by the API or elsewhere on the page. It should be safe to remove this paragraph.

jcalcaben · 2018-03-15T18:41:52Z

docs/ServiceWorkerPlugin.md

+};
+```
+
+### Purpose


I propose moving this section above Usage to make the information flow better: conceptual -> example -> API reference

jcalcaben · 2018-03-15T18:44:51Z

docs/ServiceWorkerPlugin.md

+
+### Purpose
+
+This plugin is a wrapper around the [Google Workbox Webpack Plugin](https://developers.google.com/web/tools/workbox/guides/generate-service-worker/),


Suggest splitting this into two sentences:

This plugin is a wrapper around the Google Workbox Webpack Plugin. It generates a caching ServiceWorker based on assets emitted by Webpack.

jcalcaben · 2018-03-15T18:57:41Z

docs/ServiceWorkerPlugin.md

+which generates a caching ServiceWorker based on assets emitted by Webpack.
+
+In development, ServiceWorkers can cache assets in a way that interferes with
+real-time editing and changes. This plugin takes configuration that can switch


Suggest changing the second sentence to:

This plugin can be configured to run in the following modes:

normal development - ServiceWorker is disabled

service worker debugging - ServiceWorker and hot-reloading are enabled

jcalcaben · 2018-03-15T18:59:36Z

docs/PWADevServer.md

+
+### API
+
+`PWADevServer` has only one method: `.configure(options)`. It returns a Promise


Information in this paragraph is already mentioned elsewhere on this page. It can be safely deleted.

How about we replace this whole readme with a link to devdocs?

jcalcaben · 2018-03-15T20:59:46Z

docs/ServiceWorkerPlugin.md

+
+### API
+
+


My attempt at cleaning up the API format:

ServiceWorkerPlugin

ServiceWorkerPlugin(options: PluginOptions): Plugin
Plugin constructor for the ServiceWorkerPlugin class.

PluginOptions

env: Object (Required)
An object that represents the current environment.

env.mode: String (Required)
Must be either 'development' or 'production'.

paths: Object (Required)
The local absolute paths to theme folders.

paths.assets: String
The directory for public static assets.

enableServiceWorkerDebugging: Boolean
When true, hot reloading is enabled and the ServiceWorker is active in the document root, regardless of the publicPath value.
When false, the ServiceWorker is disabled to prevent cache interruptions when hot reloading assets.

serviceWorkerFileName: String (Required)
The name of the ServiceWorker file this theme creates.
Example: 'sw.js'

runtimeCacheAssetPath: String (Required)
A path or remote URL that represents the root path to assets the ServiceWorker should cache as requested during runtime.

zetlen · 2018-04-02T13:02:19Z

@jcalcaben At long last, here's some documentation, edited down to only contain what's in this PR. Let me know what I can do to help move this long!

jcalcaben · 2018-04-02T18:03:35Z

README.md

  Divides static assets into bundled "chunks" based on components registered
  with the Magento PWA `RootComponent` interface
+- [`PWADevServer`](docs/PWADevServer.md) -- Configures your system settings and


The rest of this sentence is missing

jcalcaben · 2018-04-02T18:04:44Z

README.md

+1. Install Webpack Webpack Dev Server, and Buildpack as developer dependencies.
+
+   ```sh
+   npm install --save-dev webpack webpack-dev-server @magento/pwa-buildpack


I think webpack-cli is also needed as a dependency

DrewML · 2018-04-11T18:49:30Z

src/util/global-config.js

+    async del(...keyparts) {
+        const db = await this.constructor.db();
+        const key = this.makeKey(keyparts);
+        return new Promise((wow, ow) =>


Would appreciate if we renamed all of these in the PR to res/rej or resolve/reject. It's cute, but it's not super professional in this codebase, and just means you have to trace more code to figure out what these mean.

Agree, I really overlooked this line.

DrewML · 2018-04-11T18:50:45Z

src/util/options-validator.js

@@ -0,0 +1,39 @@
+const lget = require('lodash.get');
+const NOPE = {};


Please rename to describe what this is used for.

DrewML · 2018-04-11T19:55:27Z

README.md


-### Intro
+## Quick Setup


@jcalcaben to confirm, is this the stuff you're moving to devdocs? Seems slightly out of place in this repo

@DrewML
Yes, this content is moving to the pwa-devdocs repo.
See related Pull Request: magento-research/pwa-devdocs#20

DrewML · 2018-04-11T19:56:48Z

package.json

+    "test:dev": "run-s prettier lint jest:ci",
+    "test:watch": "jest --watch --runInBand",
+    "test:debug": "node --inspect-brk ./node_modules/.bin/jest --runInBand",
+    "test:watch:focus": "jest --watch --runInBand --coverageReporters=text --collectCoverageFrom=\"${FOCUS}/**/*.js\" --no-cache \"${FOCUS}.*\"",


Similar comment to another repo - don't want to overwhelm contributors with a billion options. This would be a good candidate for a local config

DrewML · 2018-04-11T19:58:16Z

src/ExtensionComponentWrap/.eslintrc.js

@@ -1,5 +1,8 @@
 module.exports = {
    parserOptions: {
        sourceType: 'module'
+    },
+    rules: {
+        'node/no-unsupported-features': 'off'


Comment would be helpful to provide context on why we're disabling this

This is a temporary fix anyway, since the ExtensionComponentWrap is supposed to move to Peregrine. Added a comment explaining that.

DrewML · 2018-04-11T20:00:09Z

src/index.js


 module.exports = {
    babelPluginMagentoLayout,
-    MagentoRootComponentsPlugin
+    Webpack: require('./webpack')


Webpack isn't a constructor, so it would make sense to follow JS conventions and use lowercase

True. Also keep in mind that this object will be imported by webpack.config.js, where webpack will already be present as the logical import from webpack itself.

Maybe just call this buildpack, after the module?

@DrewML I don't think it's established JS conventions that PascalCase only applies to constructors. As a quick sample, Airbnb applies PascalCase much more broadly.

@jimbo Very true that we have to find ways to make this not collide with common stuff in webpack.config.js. I can't rename it buildpack, because this grouping is specifically for objects that work in the Webpack lifecycle, be they configurators or plugins or loaders.

I think I'm going to rename it to WebpackTools. I'm also going to say we should use PascalCase for all singleton objects, not just constructors. I understand that this decision is arbitrary, but I'm considering the many PHP developers who will be reading lots of JS for the first time. The distinction between a constructor and a plain object might not be immediately clear, and the capitalization rules should appear typographically consistent and familiar.

DrewML · 2018-04-11T20:01:25Z

src/util/__tests__/debug.spec.js

+    myDebug.here(__dirname).sub('extra');
+    expect(debug.mock.calls[1][0]).toBe('pwa-buildpack:util:__tests__:extra');
+});
+afterEach(() => jest.resetAllMocks());


Nit: Would be nice to see this next to the beforeEach - I originally started a comment saying this leaked a mock because I hadn't scrolled.

DrewML · 2018-04-11T20:04:48Z

src/util/debug.js

+    return logger;
+};
+module.exports = {
+    here(p) {


Can we use a more descriptive name for this? setDebugFile or something. A single adverb doesn't really say much

DrewML · 2018-04-11T20:05:44Z

src/util/debug.js

+const root = path.resolve(__dirname, '../');
+const pkg = require(path.resolve(root, '../package.json'));
+const toolName = pkg.name.split('/').pop();
+const tokenize = (...parts) => parts.join(':');


This seems like the opposite of tokenizing 🤔

DrewML · 2018-04-11T20:07:04Z

src/util/global-config.js

+                    debug(`no cached db exists, pulling db from ${dbFilePath}`);
+                    const db = flatfile(dbFilePath);
+                    debug(`db created, waiting for open event`, db);
+                    db.on('open', () => {


What about db.on('error')? Seems like we don't handle that

DrewML · 2018-04-11T20:08:09Z

src/util/global-config.js

+            );
+        }
+        if (keyparts.length === 0) {
+            // a scalar, then


I know what a scalar is, but I'm not sure what this comment is trying to convey to me

It was a bad and confusing corner case for the GlobalConfig object, which acted like a single-value store if the key function had no parameters. I've removed it!

DrewML · 2018-04-11T20:12:12Z

src/util/global-config.js

+        return resolve(homedir(), './.config/pwa-buildpack.db');
+    }
+    static async db() {
+        if (!this._dbPromise) {


this in a static method is a reference to the class itself. If we're storing state that is shared between instances on the class itself, this feels like a singleton. Is there ever a scenario where > 1 GlobalConfig instance should be alive?

Yes! GlobalConfig instances share an underlying flat file database, but each instance of GlobalConfig has a different key prefix and key generator; this way, we can make separate namespaces without littering the user's FS with files. If it feels gross to make that a static method, I can instead make the db connection into a separate file that exports a singleton. Would that feel better?

Nah it's fine - just wanted to understand.

DrewML · 2018-04-11T20:13:00Z

src/util/global-config.js

+    async values(xform = x => x) {
+        const db = await this.constructor.db();
+        return db.keys().reduce((out, k) => {
+            if (k.indexOf(this._prefix) === 0) {


String.prototype.startsWith would be the more modern way to do this

DrewML · 2018-04-11T20:15:40Z

src/util/promisified/fs.js

@@ -0,0 +1,11 @@
+const { promisify } = require('util');


All of these can just be replaced with pify(moduleRef) using https://github.com/sindresorhus/pify

Per sindresorhus/pify#41 I think we should stick with native util.promisify, since it works with the util.promisify.custom symbol. That gives us a standard way we can normalize Node APIs with multi-argument callbacks, and the Node documentation reflects this. I like pify, but its behavior with things like child_process.exec is now nonstandard, so I think we should stay with the native here.

DrewML · 2018-04-11T20:16:45Z

src/util/run-as-root.js

+    icns: path.join(__dirname, '../../buildpack-logo.icns')
+};
+
+const elevate = async cmd =>


elevate what? Name doesn't describe the purpose without reading through the implementation

DrewML · 2018-04-11T20:18:20Z

src/util/run-as-root.js

+        });
+    });
+
+module.exports = async (fn, ...args) => {


Think this function needs a description. I can't figure out why we're spitting out a to-stringed fn to a tmp file

DrewML · 2018-04-16T14:57:56Z

docs/PWADevServer.md

+- The host must be _secure_ and _trusted_ to allow ServiceWorker operation
+- The host must be _unique_ to prevent ServiceWorker collisions
+
+urthermore, Magento PWAs are Magento 2 themes running on Magento 2 stores, so


urthermore and hey are missing letters

DrewML · 2018-04-16T14:58:56Z

docs/PWADevServer.md

+
+#### `options`
+
+- `id: string`: **Required.** A unique ID for this project. Theme name is


Would be useful to document what this id is used for (related to my other comment)

DrewML · 2018-04-16T15:01:19Z

docs/ServiceWorkerPlugin.md

+            /* other plugins */
+            new ServiceWorkerPlugin({
+                env: {
+                    mode: 'development'


Is this just development or production? If so, as a plugin, the code already has access to read webpack 4's mode setting (required field in config). So we don't need to manually specify here. Less chance for bugs to creep in from bad configs

Believe the config will be available on compiler.options in your plugin

@DrewML Have you been moving everything to Webpack 4? I got bit by a breaking API change this morning, which reminded me that we ought to probably do that carefully.

Also, the mode could be other values, like test or stage.

We're very close - I need to review and merge the open PR from #21 and do some testing.

We don't have to switch to mode until then, but I'd like to use a different term in our plugin so we're not overloading what mode means in a webpack config (mode in webpack 4 only accepts 2 values).

How about phase?

DrewML · 2018-04-16T15:04:59Z

src/WebpackTools/MagentoResolver.js

+        return {
+            modules: [options.paths.root, 'node_modules'],
+            mainFiles: ['index'],
+            extensions: ['.js']


This is overriding webpack's default .json entry, which is going to surprise anyone who is used to JSON imports working with node/webpack OOTB

Oh, whoops!

DrewML · 2018-04-16T15:05:56Z

src/WebpackTools/PWADevServer.js

+    }),
+    hostnamesById: new GlobalConfig({
+        prefix: 'devhostname-byid',
+        key: x => x


Can key just default to an identity func?

That would be a footgun because key has to return a string, but I can make its default Object.prototype.toString.call.

Yeah, or could just default to String

Switched it to toString

DrewML · 2018-04-16T15:08:10Z

src/util/options-validator.js

+    }
+}
+
+module.exports = (name, simpleSchema) => (callsite, options) => {


Why not just use joi or JSON schema here? I'd imagine you're going to hit the edges of this pretty quick, and we'll quickly end up in the business of writing an options validator.

No good reason! I had always intended to, but I was moving fast. Seems like tech debt we could pay off later, though; do you want to hold up merge until we switch to joi?

No need to hold up, but a comment with a TODO would be cool. Easy "good first issue" to throw up later

DrewML · 2018-04-16T15:13:06Z

package.json

-    "test:dev": "jest --watch",
-    "jest:ci": "jest -i --forceExit --testResultsProcessor=./node_modules/jest-junit-reporter",
+    "test:dev": "run-s prettier lint jest:ci",
+    "test:watch": "jest --watch --runInBand",


--runInBand is going to slow down watching in development - doubt that was the intention here?

Yeah, I meant for that to be in a debug and not a watch.

DrewML · 2018-04-16T15:23:58Z

src/util/run-as-root.js

+        await unlink(scriptLoc);
+        throw e;
+    }
+    // do a finally


Whoops, gotta update that comment. I had discovered that the semantics of finally are somewhat different with async/await. Here is a demo I cooked up about it.

And a relevant GitHub comment about same.

Given the confusion I thought I should avoid finally.

I had discovered that the semantics of finally are somewhat different with async/await.

I'm confused - your example shows that try/catch/finally works the exact way I'd expect. It's Promise.prototype.finally that can be confusing, but you're using async/await here so I'm not quite grokking how that plays into this?

Can you explain what you're wanting to do in a finally block?

Welp, I'm an idiot. I got the behavior backwards in my head--the finally is fine. (I just wanted to delete a temp file)

Nope, not an idiot! Just the rush to Imagine

Here's a cool doggo

DrewML · 2018-04-17T16:18:01Z

I pushed a commit to your branch to fix CI

DrewML · 2018-04-19T15:11:45Z

src/WebpackTools/PWADevServer.js

+                PWADevServer.findFreePort()
+            ]);
+
+            await PWADevServer.hostnamesById.set(id, hostname);


Can these 2 await calls run in parallel?

I don't remember, but since they were both touching the flat file I felt like playing it safe.

DrewML · 2018-04-19T15:16:20Z

src/WebpackTools/PWADevServer.js

+            return maybeHostname;
+        } else {
+            debug(`findFreeHostname: ${maybeHostname} bound to port`, exists);
+            return PWADevServer.findFreeHostname(identifier, times + 1);


Consider adding a max # of times and a bail out

DrewML · 2018-04-19T15:18:36Z

src/WebpackTools/__tests__/PWADevServer.spec.js

+    GlobalConfig.mockImplementation(({ key }) => ({
+        set: jest.fn((...args) => {
+            const keyParts = args.slice(0, -1);
+            expect(typeof key(...keyParts)).toBe('string');


It's strange to me to have an assertion inside of a mock. Think it would make more sense to be checking .calls in the test

DrewML · 2018-04-19T15:24:22Z

src/WebpackTools/middlewares/OriginSubstitution.js

@@ -0,0 +1,60 @@
+/**


Aren't we going to have misses with this strategy? background-image in external stylesheets is the first that comes to mind, but I have to assume there are more.

There are more for sure. This is a stopgap until we can hack Magento Framework to have branch logic in their asset URL resolvers.

Seems like what you just mentioned would be useful in this prelude

DrewML · 2018-04-19T15:46:32Z

src/util/run-as-root.js

+    } finally {
+        await unlink(scriptLoc);
+    }
+    // do a finally


I think you meant to remove this comment

I think I did a finally is rememberinged.

zetlen · 2018-04-22T18:27:20Z

If this passes CI, I'm gonna merge this before full approval and we can resolve issues later--it's important for demo and community purposes to have this functionality there.

zetlen requested review from rowan-m, jimbo, jcalcaben and DrewML March 12, 2018 14:48

zetlen mentioned this pull request Mar 12, 2018

chore: Remove devtools and switch to pwa-buildpack magento-research/venia-pwa-concept#35

Closed

zetlen force-pushed the zetlen/add-webpack-configurators branch from 2e6af99 to acbad80 Compare March 12, 2018 17:51

jcalcaben reviewed Mar 15, 2018

View reviewed changes

ericerway assigned zetlen Mar 30, 2018

ericerway added this to the Milestone 2 milestone Mar 30, 2018

jcalcaben reviewed Apr 2, 2018

View reviewed changes

zetlen force-pushed the zetlen/add-webpack-configurators branch 2 times, most recently from e6364e9 to d2aa782 Compare April 6, 2018 17:51

DrewML reviewed Apr 11, 2018

View reviewed changes

DrewML reviewed Apr 16, 2018

View reviewed changes

zetlen and others added 2 commits April 17, 2018 10:06

fix: PR updates from feedback

115dcce

Add back run in band setting to jest:ci script

03497a6

DrewML reviewed Apr 19, 2018

View reviewed changes

zetlen added 9 commits April 21, 2018 15:37

fix: tweaks based on PR feedback

59a240f

prepare for mainline release

0ef7b48

feat: add custom middleware handler to PWADevServer

719a5ca

style: add comments and first issue tags

6e693ff

fix: style

b6f7693

fix: add sanity check to findFreeHostname

ab4da0e

test: remove unnecessary mock impl

a4ea725

style: additional comment

51fd50d

fix: remove trailing comment text

3986e8b

zetlen removed request for rowan-m and jimbo April 22, 2018 18:27

zetlen merged commit 399c00e into master Apr 22, 2018

DrewML mentioned this pull request May 2, 2018

suggested edit for readme #24

Merged

		@@ -0,0 +1,56 @@
		## MagentoResolver

		Adapter for configuring Webpack to resolve assets according to Magento PWA conventions.

		```


		- ⚠️ `MagentoResolver.configure()` is async and returns a Promise, so a Webpack


		### Purpose

		Generates a configuration for use in the [`resolve` property of Webpack config](https://webpack.js.org/configuration/resolve/).


		### API

		`MagentoResolver` has only one method: `.configure(options)`. It returns a Promise


		### Purpose

		This plugin is a wrapper around the [Google Workbox Webpack Plugin](https://developers.google.com/web/tools/workbox/guides/generate-service-worker/),


		### API

		`PWADevServer` has only one method: `.configure(options)`. It returns a Promise

		@@ -0,0 +1,39 @@
		const lget = require('lodash.get');
		const NOPE = {};


		#### `options`

		- `id: string`: Required. A unique ID for this project. Theme name is

Add webpack configurator tools #20

Add webpack configurator tools #20

Conversation

zetlen commented Mar 12, 2018 • edited Loading

ServiceWorkerPlugin

Purpose

Notes

PWADevServer

Usage

Purpose

Notes

MagentoResolver

Purpose

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ServiceWorkerPlugin

PluginOptions

zetlen commented Apr 2, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DrewML Apr 11, 2018 • edited Loading

Choose a reason for hiding this comment

DrewML Apr 11, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DrewML Apr 17, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zetlen Apr 17, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zetlen commented Mar 12, 2018 •

edited

Loading

`ServiceWorkerPlugin`

`PluginOptions`

DrewML Apr 11, 2018 •

edited

Loading

DrewML Apr 11, 2018 •

edited

Loading

DrewML Apr 17, 2018 •

edited

Loading

zetlen Apr 17, 2018 •

edited

Loading