importScripts using Workbox + workbox-build can lead to broken SW

[gauntface]

@beatrizdemiguelperez pointed this out on the Slack channel.

If you add an importScript that uses the workbox API and workbox-build calls workbox.setConfig(), the service worker throws with workbox-sw.js:1 Uncaught Error: Config must be set before accessing workbox.* modules to account for the fact that this is probably not intended.

@jeffposnick the easiest solution is to call setConfig before importing additional scripts.

[jeffposnick]

Here's the relevant template that workbox-build uses:

workbox/packages/workbox-build/src/templates/sw-template.js

Lines 30 to 36 in 505122f

	<% if (importScripts) { %>
	importScripts(
	<%= importScripts.map(JSON.stringify).join(',\\n ') %>
	);
	<% } %>
	<% if (modulePathPrefix) { %>workbox.setConfig({modulePathPrefix: <%= JSON.stringify(modulePathPrefix) %>});<% } %>

The way I'm interpreting this issue is that there needs to be some way of segregating the importScripts values, so that there's a single call to the importScripts('path/to/workbox-sw.js') first, then the call to workbox.setConfig(), and then another importScripts(...), where ... is all of the other individual script files.

This might be doable by searching through the importScripts array and finding the URL that ends with workbox-sw.js, if we could safely assume that that's always going to exist. (I guess it would if importWorkboxFrom is set to 'local' or 'cdn'.)

Or we might want to encourage a model in which you could disable the automatic workbox.setConfig(), and developers would be responsible for calling it themselves inside of the custom script that's being imported, but I think it would be difficult for developers to figure out the correct path to use.

I'm inclined to go for the first approach, unless anyone else has any ideas. How does that sound, @beatrizdemiguelperez & co.?

[gauntface]

+1 to the seperate of workbox.js and using it that way.

[beatrizdemiguelperez]

Great. +1 first option. Thanks!