-
Notifications
You must be signed in to change notification settings - Fork 5
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
Not support MV3 native ES background worker #24
Comments
I read your comment in the release notes. It's technically right that the worker only supports My setup looks like: "background": {
"service_worker": "background.worker.js",
}, // background.worker.js
self.importScripts("./background.js"); Where:
In my case I think it's failing because For my use case (i.e. adding the new WebExtensionTarget({
weakRuntimeCheck: true,
// Required to support sandboxed iframes
// https://github.com/awesome-webextension/webpack-target-webextension/pull/42
background: {
pageEntry: "background",
},
}), |
|
I'm unsure if your comment relates to this issue, but I'll write down what I recently found as a memo. Firstly, Chrome supports service workers with native ES modules now, you need to write your manifest like this: "background": {
"service_worker": "background.worker.js",
"type": "module"
}, Then the service worker can use Currently, we use JSONP-style (the default of webpack) to load chunks, this way works well, so even if this issue is not resolved, this plugin is ok to use. // JSONP-style chunk format
"use strict";
(globalThis["webpackChunk"] = globalThis["webpackChunk"] || []).push(...) As an ES Module enthusiast, I hope we can support ES Module as the chunk format, and also as the chunk loading format. // ES Module chunk format
export const id = 232;
export const ids = [232];
export const modules = {
/***/ 232:
/***/ (() => {
/***/ })
}; If the chunk format becomes ESM, the only way to load it is static Dynamic This becomes harder, but not impossible. I think it needs a lot of time to figure out how to make this work. I can emit import statements at the top level, but I need to know their file name, but unluck, file names are generated from a runtime function ( Since everything works well today, this is not very urgent to fix. |
That's very good to know. Parcel forced me to use that syntax but never investigated it. I'll start using it in webpack too because importScript breaks "Pause on uncaught errors" in the dev tools, because the debugger pauses on importScript, regardless of the actual position and source maps. |
Native ES service worker works, dynamic import does not. While using this plugin, compiled ES modules (including dynamic import) work after bundling, loading by |
Blocked by w3c/ServiceWorker#1356, otherwise, we need to emit import statements which is not easy in a webpack bundle.
The text was updated successfully, but these errors were encountered: