Proposal/RFC: workbox-webpack-plugin changes

[developit]

👋 Hi all!

I put together a proposal for how we might modify workbox-webpack-plugin to allow for a more bundler-centric development approach, using Workbox as a modular library and Webpack to bundle the resulting ServiceWorker.

You can view the proposal here: https://docs.google.com/document/d/1qyzxo5MBZ5BHva2GaAPk_Hw-jkVk1-NXcqfAIlvHgkc

Comments welcome!

[mcshaman]

Cool. Questions:

1. In your proposal are you suggesting doing away with the webpackbootstrap and just using the importScript to import chunks?
2. You only seem to mention modules from workbox. What about other modules either relative or in the node_modules folder? Will they be bundled under this proposal and if so can they be bundled into a single service worker file or is the proposition to have them as a seperate chunk?

[madmoizo]

My wishes for v5:

• importWorkboxFrom values are enum only ['local', 'disabled', 'cdn'], no more chunks
• importScripts supports chunks
• import order should be:
  • importWorkboxFrom (if not disabled)
  • precache-manifest.js
  • importScripts list

This gives full control over precache-manifest assets to the developper. Breaking change: if you want to change __precacheManifest it has to be explicit

__precacheManifest = __precacheManifest.concat([{
   url: 'nonAssetScript.js',
   revision: 'abcdefg'
}])

The solution was to “teach” Webpack to detect Service Workers by introducing parser logic for navigator.serviceWorker.register()

Parser seems to match simple cases https://github.com/GoogleChromeLabs/squoosh/blob/master/config/auto-sw-plugin.js#L73 what about:

const n = navigator.serviceWorker
n.register()

Should this be a new plugin?

It can't be just a flag ?

[developit]

@mcshaman:

In your proposal are you suggesting doing away with the webpackbootstrap and just using the importScript to import chunks?

No - webpack's bootstrapping code uses importScripts() when the output target is set to webworker.

You only seem to mention modules from workbox. What about other modules either relative or in the node_modules folder? Will they be bundled under this proposal and if so can they be bundled into a single service worker file or is the proposition to have them as a seperate chunk?

This would support importing from node_modules using the same webpack semantics as main thread code. I believe @jeffposnick had some good arguments against the use of dynamically loaded code in Service Workers (blocking on importScripts, import error handling, code caching issues)

@frlinw A flag might be good, yeah.

[wood1986]

My wish for v5,

• when people use InjectManifest,
  • swSrc option should become unless and it should fall into a case that bring your own chunk(BYOC). This means it goes to the default case directly in workbox/packages/workbox-webpack-plugin/src/lib/get-workbox-sw-imports.js line 52.
  • Currently I am unable to use to my own bundles.
  • As I choose to use my own bundles, I will not use importScript and I will ask webpack handles all dependencies and pack them into a file. Currently, I can only use importScript and I cannot use other libraries with import statement in the service-worker.js
  • it should inject and prepend the manifest at the top of my bundle.
• As for GenerateSW, you can create a default chunk template will be passed and then call InjectManifest. With that, you do not have to think about the minification.

---

I did some research on how the plugin can be implemented for bring your own chunk(BYOC). I think one webpack config, two entries, and one plugin is not feasible. Because at runtime, the bundle is using window instead of self as the global. it needs multiple target for different entries. And webpack does not support that Not only that, it is difficult for people to configure especially in optimization because you do not want the service worker depends on vendors.

Because of the previous limitation, I tried to return multiple configs with different targets. But before injecting the manifest to your own sw.js bundle, you need to wait the index entry compilation to complete. This means two configurations need to have some communication before the manifest injection. But this is way easier and cleaner than one webpack config, two entries, and one plugin. The downside is it needs two plugins.

[wood1986]

I have just created a plugin for my wish. You can take it if you want. Check https://github.com/wood1986/workbox-poc/tree/multiple-configs

[jeffposnick]

That sounds like the best stop-gap approach in the meantime—I'm glad you're able to enable your use case while we work on the formal v5 release.

[wood1986]

That sounds like the best stop-gap approach in the meantime—I'm glad you're able to enable your use case while we work on the formal v5 release.

Thanks for checking it out. I hope you guys can take my work. If not, can you guys share your concerns? I can think about it.

[jeffposnick]

This should be addressed by the current Workbox v5.0.0 alpha.

[madmoizo]

Because at runtime, the bundle is using window instead of self as the global. it needs multiple target for different entries. And webpack does not support that

@wood1986 I has a similar issue. Try globalObject: 'this' https://webpack.js.org/configuration/output/#outputglobalobject

{
  entry: {
    'app': `${rootPath}/src/app/main.js`,
    'sw': `${rootPath}/src/sw/main.js`
  },
  output: {
    publicPath: '/',
    globalObject: 'this' // fix window is not defined issue
  }
}

For the plugins part, importWorkboxFrom supports chunks when importScripts doesn't, so just use importWorkboxFrom to import your chunk.

{
  plugins: {
    new WorkboxPlugin.InjectManifest({
      swSrc: `${rootPath}/src/sw.js`,
      importWorkboxFrom: 'sw', // chunk name supported !
      include: [
        /\.html$/,
        /\.js$/,
        /\.css$/,
        /\.woff2$/,
        /\.jpg$/,
        /\.png$/
      ]
    })
  }
}