Vulcanization breaks sw-toolbox-setup.js import in platinum-sw-cache

[hawkett]

This line of platinum-sw-cache.html:

importscriptLate: new URL('bootstrap/sw-toolbox-setup.js', baseURI).href,

is intended to be relative to platinum-sw-cache.html, with the baseURI established on this line of platinum-sw-register.html:

var baseURI = document.currentScript ? document.currentScript.baseURI : './';

When vulcanizing (e.g. an elements.html file similar to that in the polymer start kit), the baseURI is determined to be the location of the vulcanized output (e.g. elements.build.html) and the path to sw-toolbox-setup.js is incorrect.

In its current form, this looks like it would be difficult for vulcanize to fix in a generic way given that the baseURI is passed in.

Would it make sense to solve this by adding support for overriding the baseURI explicitly via an attribute/property on platinum-sw-register?

[addyosmani]

I personally wouldn't be opposed to supporting baseURI overriding via an attribute, but there may be additional nuance here worth discussing. Looking in @jeffposnick for his take.

[jeffposnick]

That scenario is taken care of explicitly in Polymer Starter Kit's build by copying over the bootstrap directory to the elements directory.

The problem I see with trying to override this via a configurable baseUri is that the page hosting the element needs to know whether it's running in a vulcanized or unvulcanized environment, and then adjust the inline baseUri value at runtime accordingly. My thinking is that it's cleaner to assume a model where the build process takes care of putting everything where it needs to go, and the runtime uses a static configuration that doesn't change between environments.

If you can think of a clean, generic way to deal with actually setting the different runtime configurations, I'd definitely be open to hearing about it.

[hawkett]

I don't think that's true re. the page hosting the element needing to be aware of the vulcanized vs. unvulcanized - bootstrap/sw-toolbox-steup.js is always in the same place regardless of vulcanization (i.e. in the bower directory). It can be supplied via a property as set-and-forget.

[jeffposnick]

I can envision serving scenarios in which there isn't a consistent absolute path that points to the bower_components directory across dev/production environments, but okay, that possibility doesn't prevent us from adding in a baseUri option for those who would prefer to use it.

I'll put together a PR.

[hawkett]

Thanks Jeff - seems in general people would want to avoid having to change their build to use a component, but agree both cases will exist.