Allow Strategy subclasses to deny usage of certain lifecycle callbacks

[jeffposnick]

trafficstars

Library Affected: workbox-srategies

Something I've been thinking about for v6, especially in the context of the new PrecacheStrategy, is the idea of allowing a Strategy subclass to opt-out of support for certain lifecycle callbacks. For instance, a Strategy might want to prevent any plugin from implementing a cacheWillUpdate or cacheKeyWillBeUsed callback, if it "knows" that it's a bad idea for consumers of that Strategy to override logic that it's counting on.

If this sounds like a good idea, we'd have to determine the DX bit; presumably what would be most in keeping with our current practice is throwing a runtime exception in our development builds if a developer adds in a plugin with a prohibited callback, and just silently not running that callback in our production builds. Alternatively, we could throw in both development and production.

CC: @philipwalton for thoughts.

[jeffposnick]

Thinking about this a bit further, a few more obvious use cases:

• The NetworkOnly strategy should prohibit the usage of any plugins that deal with cache updates.
• The CacheOnly strategy should do the same, for fetch-related plugins.
• etc.

I also wonder whether we could get clever with the TypeScript definitions so that we not only enforced runtime checks, but also managed to get TypeScript to complain if a plugin is passed to a strategy that prohibits one of its lifecycle callbacks.

[jeffposnick]

Based on https://github.com/GoogleChrome/workbox/issues/2178#issuecomment-745661820, I wonder if we should prioritize this first as a non-breaking change (where we just warn in development mode) and then in v7 actually throw runtime errors if folks violate the per-Strategy restrictions.