feat: add assetsHash for cache naming

[nename0]

What is accomplished by your PR?

This PR adds another parameter to the options passed to the transformOptions function. It's an hash of the assets-filename array. I use this for the naming of the cache in the SW, because the jsonStats param does not contain anything useful for naming. Whenever the array of file(name)s to cache changes, so does the assetsHash therefore a new cache is opened and loaded with the new files.
Example implementation (a transformOptions function which passes on the assetsHash is needed):

var serviceWorkerOption = ...
const staticCacheName = 'static-' + serviceWorkerOption.assetsHash;
self.addEventListener('install', (event) => {
    event.waitUntil(caches.open(staticCacheName).then((cache) =>
        cache.addAll(serviceWorkerOption.assets)
    ));
});
self.addEventListener('activate', (event) => {
    const deleteOldCaches = caches.keys().then((cacheNames) =>
        Promise.all(cacheNames.filter((cacheName) => staticCacheName !== cacheName)
            .map((cacheName) => caches.delete(cacheName))
        )
    );
    event.waitUntil(deleteOldCaches);
});

Is there something controversial in your PR?

Maybe the default transformOptions function should pass on the assetsHash?

Checklist

• Run unit tests to ensure all existing tests are still passing
• Add new passing unit tests to cover the code introduced by your PR
• Change the documentation
• add an example???

[woutervanvliet]

Thanks for this PR, it's actually something that I'll be needing myself in the near future.

Just got a few tiny remarks about the tests, but otherwise I'm quite happy.

[woutervanvliet]

As the input is known, so is the output - could you update the test case and let it test against the actual expected value of the hash?

[woutervanvliet]

Perhaps you can add a second test case, with a different mocked source, as evidence that the hash is something else when the contents change.

[nename0]

Oh I think we've a design decision here. Maybe I didn't explain fully, but currently only the filenames get hashed not the contents. In my project I use filenames with hashes so there is no problem with this. On the other hand after reading this I think the only real use case to make the assetsHash include the content would be to make the serviceworker byte different when the assets change, but not their filenames. In this case it would probably be easier to just make the jsonStats include the compilation hash by changing this line to true.
What do you think @woutervanvliet ?

[woutervanvliet]

Think I indeed misunderstood the point of your PR, but yes - my approach would be to have some kind of value, that's the same between builds of the same code, but different when sourcecode changes.

Tbh; I'm not that familiar with webpack internals, but it sounds like enabling the hash would solve the same problem as your PR does.

@devCrossNet @oliviertassinari What do you say?

[ghost]

pls merge this uwu