Closed DibyodyutiMondal closed 2 years ago
Should I just go ahead and submit a pull request for this?
I can't imagine many folks will end up needing this, but sure, if it helps your use case, it seems fine. Please file a PR.
If you could also update https://github.com/GoogleChrome/workbox/blob/85bdecd24ded38c215b4e8943ee9b3eb0e2c3ee9/packages/workbox-webpack-plugin/src/generate-sw.ts#L72 in your PR, that would be cleanest, to keep InjectManifest
and GenerateSW
consistent.
@jeffposnick Any idea when changes will propagate to npm?
Library Affected:
workbox-webpack-plugin
Issue or Feature Request Description: So, I am making a plugin that allows me to use workbox with angular, and I use typescript. Even my webpack config uses typescript. As part of this effort, I use a class that inherits from
InjectManifest
. I need to addindex.html
andmanifest.webmanifest
toadditionalManifestEntries
. This addition needs to be done not just during the initial webpack config setup. Rather, it must be done every time compilation runs (which is every time I make a change and save), so that I can add the compilation hash as the revision number for the two entries. This lets the existing service worker know that some file has changed somewhere, without having to add any lazy-loaded modules to the manifest entries.For this, I need access to the
config
property of theInjectManifest
class which I inherit from, but it is marked asprivate
, so I cannot access it. As illustrated by my example above, this is poor for extensibility. If possible, I recommend making itprotected
instead ofprivate
. That way, it remains private. But those who want to extend the behavior of the plugin can do so easily.Currently, the workaround for this is to go into the
node_modules
folder and manually edit the.d.ts
. This has enabled me to successfully finish my plugin, but I will have to keep returning to this whenever a new version of workbox releases.