.html extension stripping issues

[jeffposnick]

We went with the decision that the non-.html version of our URLs would be authoritative, and have a HTTP 301 redirect from .html to non-.html enforced by our Firebase config: https://github.com/GoogleChrome/workbox-microsite/blob/master/firebase.json#L4

There are a couple of things we could improve about the site to account for this:

• We're using the .html version of the URL in our <link rel="canonical" href="/reference-docs/latest/module-workbox-background-sync.html"> tags.
• We're linking to the .html versions of the docs pages from within the "Reference" drop down.
• Our precache manifest has the .html versions of URLs. That means that only requests made for the .html flavor of the URL will work offline. (We can work around this by using templatedUrls to establish a mapping whose keys were the URL without .html, and whose values were the underlying files with .html.)

Or.... we could just turn off the setting in the Firebase config that enables the non-.html 301 redirects, and not really have to change anything else.

[gauntface]

Most of this is easy and done in branch ref-docs-html.

I'm not a fan of the templatedUrls simply because I'm assuming we'll have to do a templatedUrl for every entry and this feels like a common enough thing that it shouldn't be so difficult.

We could a callback function that allows a developer to intercept final precache options (i.e. the filename and the revision) and let them alter and return the value and that's what get's used in the service worker.

This can be considered a last resort for developers wanting to add some custom logic / behavior to the files precache list.

[jeffposnick]

Seeing up templatedUrls can be automated via glob() + array manipulation, which is kinda-sorta like a callback, but one at build time.

It sounds like you're suggesting a runtime callback, which would be a good alternative, if the API surface is clear enough.