Workbox: Requiring workbox-sw as a CommonJS module

[jeremija]

Library Affected:
workbox-sw

Issue or Feature Request Description:
Are there any plans for supporting require('workbox-sw') as as CommonJS module? For example, browserify doesn't seem to support pkg.module as it is still just a proposal. Appending something like this to the importScripts build output would help those who depend on browserify:

if (typeof module !== 'undefined' && module.exports) {
  module.exports = WorkboxSW
}

[gauntface]

cc @jeffposnick @philipwalton @addyosmani what do you think about this?

Personally I don't see this as a bad idea. Setting the package.json main value to a commonjs file would definitely make more sense than an iife built to be used in the browser. What do you think?

[jeffposnick]

There are a few potential drawbacks:

• There's a 212 byte overhead when switching from the iife to umd bundle for the v2 prod build of workbox-sw. I'm assuming that's consistent across the other packages. (This wouldn't be an issue if we explicitly shipped cjs in addition to iife and es2015 bundles, but then we'd have three different bundle formats instead of just two.)
• The use of importScripts('path/to/versioned-file.v###.js') is cache-efficient, and can lead to a meaningful decrease in the number of bytes that a return visitor to a PWA downloads over the course of their interaction with a site. If the workbox-sw code is inlined in the top-level service worker, then it ends up being redownloaded each time the other contents (presumably the precache manifest) change. This is a problem when consuming Workbox as an ES2015 module, too, but at least in that scenario, it's possible to pull in smaller chunks of the code via the named exports.

It's worth evaluating those drawbacks against the benefits for Browserify users in the context of the v3 packaging/loading setup.

[gauntface]

Gonna put this issue as chillin for now.

I'm still open to this, but there is a lot going on with V3 and you are the first person to request this feature. If others would like this then please do thumbs up or comment and we can circle back round to this.

[gauntface]

I'm going to close this issue, if anyone wants this feature please feel free to re-open this issue.

[DecentM]

It'd be great if this was implemented.
I'd like to migrate from sw-toolbox to workbox-sw, but since I transform all my JS with Browserify, I can't.
For example, this is how my current worker with sw-toolbox looks:

import toolbox from 'sw-toolbox'

/* some logic */

toolbox.precache(things)

Compared to that, trying the same with workbox-sw fails:

import WorkboxSW from 'workbox-sw'
const workbox = new WorkboxSW()

/* register routes, etc */

workbox.precache([])

// -> Uncaught TypeError: WorkboxSW is not a constructor

Indeed, WorkboxSW is undefined.
I'm not familiar with Webpack, but from a quick glance, it looks like it would work if the WorkboxSW class was exported from packages/workbox-sw/controllers/WorkboxSW.mjs in the main entry point.

[jeffposnick]

The following code will work:

importScripts('path/to/workbox-sw.js');

const workbox = new WorkboxSW()

// Do something with `workbox`.

workbox-sw.js needs to be either a local URL of a copy of the library we distribute, or it could point to an "unofficial" CDN URL like https://unpkg.com/[email protected]/build/importScripts/workbox-sw.prod.v2.1.1.js. In Workbox v3, we make it easier to refer to a copy of the Workbox libraries via an official CDN URL.

The importScripts() call will take care of executing the Workbox code in the context of the service worker, and that code will automatically define the WorkboxSW interface in the service worker's global scope. It's not necessary to explicitly bundle in the Workbox code in order to accomplish what you're trying to do.

[DecentM]

I know it's not _necessary_ to bundle it, but I'd much prefer to skip the extra HTTP request.
Bundling also provides the flexibility to post-process the created worker, like minifying, or importing other modules in one build step.

[gauntface]

I'm open to supporting this workflow if anyone is willing to have a stab at a PR. We've gone to a lot of effort to enable importing for a rollup build process, so it would be nice to have a browserify support as well.

[jeffposnick]

FWIW, you can skip the extra HTTP request and post-process the final file if you explicitly concatenate the full Workbox JavaScript code into your browserify output, via something like https://stackoverflow.com/questions/36329775/gulp-browserify-then-concat-files

(It's going to be harder to do this in v3 than it is in v2, since we ship smaller standalone files that would each need to be concatenated in order to get the full Workbox codebase.)

[gauntface]

I'm going to close this for now. With v3 we should be in a better place for ES module support and ideally everyone would be using this.