Workbox: Different hashes for templatedUrls and original file

[piehei]

Library Affected:
workbox-build

Browser & Platform:
all browsers

Issue or Feature Request Description:

I use workbox-build as the last step of my gulp process. It's configured like so:

gulp.task('bundle-sw', () => wbBuild.injectManifest({
    globDirectory: './dist/',
    swSrc: './src/service-worker.js',
    swDest: './dist/service-worker.js',
    globPatterns: ['**/*.{html,js,css,woff,woff2,eot,svg,png,json}'],
    globIgnores: ['service-worker.js', 'static\/json\/**'],
    templatedUrls: {
      '/': ['index.html']
    }
})
...

I added templatedUrls as noted here https://github.com/GoogleChrome/workbox/issues/758 in order to have a workaround for ignoring url parameters (I want to have /?home=1 for home screen adders). However, I noticed that the generated service-worker.js has these entries:

workbox.precache([
  {
    "url": "index.html",
    "revision": "6bafce7795e4c393ccc4d201151a432c"
  },
...
  {
    "url": "/",
    "revision": "ee942f6ef2fcc3a8193ec0c9b4d874af"
  }
]);

Not being completely aware of how the library works this immediately caught my attention. My gut says the hashes should be the same since I think I'm routing everything that tries to hit the '/' route to '/index.html' and dropping all params at the same time.

Is this intentional, and if so, what am I missing here?

Thank you for the great tools.

[gauntface]

Yeah this feels pretty weird / wrong to me. I'll have a crack at writing a small test case for this and double check the behavior.

Thanks for the bug report :)

[jeffposnick]

There's different logic used for generating the hashes for entries in globPatterns vs. entries in templatedUrls.

For globPatterns, we take the MD5 hash of each file.

The templatedUrls logic effectively concatenates all of the individual hashes, and returns a hash of that concatenated string, ensuring that if any of the individual hashes change, the overall hash changes.

The MD5 hash of '6bafce7795e4c393ccc4d201151a432c' is 'ee942f6ef2fcc3a8193ec0c9b4d874af', which explains what you're seeing.

I don't think there's any benefit of adding in special logic to return the underlying hash, instead of the hash-of-hash, when templatedUrls is passed on a single dependency. This amounts to an implementation detail.

[gauntface]

@jeffposnick Is there an issue here that precaching will cache the index.html file twice (And update twice) in the above example?

[jeffposnick]

Yes, the configuration in https://github.com/GoogleChrome/workbox/issues/763#issuecomment-329652200 would end up caching index.html twice, once with / as the cache key, and once with /index.html. And then have to keep each up to date.

It's not ideal, and now that the fix for https://github.com/GoogleChrome/workbox/issues/758 is deployed, it shouldn't be necessary anymore.