New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal/RFC: workbox-webpack-plugin changes #1854
Comments
Cool. Questions:
|
My wishes for v5:
This gives full control over precache-manifest assets to the developper. __precacheManifest = __precacheManifest.concat([{
url: 'nonAssetScript.js',
revision: 'abcdefg'
}])
Parser seems to match simple cases https://github.com/GoogleChromeLabs/squoosh/blob/master/config/auto-sw-plugin.js#L73 const n = navigator.serviceWorker
n.register()
It can't be just a flag ? |
No - webpack's bootstrapping code uses importScripts() when the output target is set to webworker.
This would support importing from node_modules using the same webpack semantics as main thread code. I believe @jeffposnick had some good arguments against the use of dynamically loaded code in Service Workers (blocking on importScripts, import error handling, code caching issues) @frlinw A flag might be good, yeah. |
My wish for v5,
I did some research on how the plugin can be implemented for bring your own chunk(BYOC). I think one webpack config, two entries, and one plugin is not feasible. Because at runtime, the bundle is using Because of the previous limitation, I tried to return multiple configs with different targets. But before injecting the manifest to your own sw.js bundle, you need to wait the index entry compilation to complete. This means two configurations need to have some communication before the manifest injection. But this is way easier and cleaner than one webpack config, two entries, and one plugin. The downside is it needs two plugins. |
I have just created a plugin for my wish. You can take it if you want. Check https://github.com/wood1986/workbox-poc/tree/multiple-configs |
That sounds like the best stop-gap approach in the meantime—I'm glad you're able to enable your use case while we work on the formal v5 release. |
Thanks for checking it out. I hope you guys can take my work. If not, can you guys share your concerns? I can think about it. |
This should be addressed by the current Workbox v5.0.0 alpha. |
@wood1986 I has a similar issue. Try {
entry: {
'app': `${rootPath}/src/app/main.js`,
'sw': `${rootPath}/src/sw/main.js`
},
output: {
publicPath: '/',
globalObject: 'this' // fix window is not defined issue
}
} For the plugins part, {
plugins: {
new WorkboxPlugin.InjectManifest({
swSrc: `${rootPath}/src/sw.js`,
importWorkboxFrom: 'sw', // chunk name supported !
include: [
/\.html$/,
/\.js$/,
/\.css$/,
/\.woff2$/,
/\.jpg$/,
/\.png$/
]
})
}
} |
👋 Hi all!
I put together a proposal for how we might modify
workbox-webpack-plugin
to allow for a more bundler-centric development approach, using Workbox as a modular library and Webpack to bundle the resulting ServiceWorker.You can view the proposal here:
https://docs.google.com/document/d/1qyzxo5MBZ5BHva2GaAPk_Hw-jkVk1-NXcqfAIlvHgkc
Comments welcome!
The text was updated successfully, but these errors were encountered: