Not support MV3 native ES background worker

[Jack-Works]

Blocked by w3c/ServiceWorker#1356, otherwise, we need to emit import statements which is not easy in a webpack bundle.

[fregante]

I read your comment in the release notes. It's technically right that the worker only supports importScripts, but not if the file itself was already imported via importScripts

My setup looks like:

  "background": {
    "service_worker": "background.worker.js",
  },

// background.worker.js
self.importScripts("./background.js");

Where:

• background.worker.js is a static JS file outside webpack and
• background.js is the webpack output and candidate for serviceWorkerEntry.

In my case I think it's failing because serviceWorkerEntry: 'background' will change the primary loading style, which isn't available past the first background.worker.js

For my use case (i.e. adding the onMessage handler to run executeScripts), I think that maybe it already works with this, regardless if manifest version:

      new WebExtensionTarget({
        weakRuntimeCheck: true,

        // Required to support sandboxed iframes
        // https://github.com/awesome-webextension/webpack-target-webextension/pull/42
        background: {
          pageEntry: "background",
        },
      }),

[fregante]

I think that maybe it already works with this, regardless if manifest version:

Yep: pixiebrix/pixiebrix-extension#7472

[Jack-Works]

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 import or export statements, not importScripts.

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 import or dynamic import.

Dynamic import already works to load JSONP-style chunks in the content script (https://github.com/awesome-webextension/webpack-target-webextension#content-script), the problem is dynamic import is not allowed in an ES Module service worker even if the dynamic import is called before first event loop ends. This requires me to emit not dynamic import, but static imports. Webpack now only supports dynamic import (see __webpack_require__.f.j if you're interested) those chunks.

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 (__webpack_require__.u) and it's very hard to do it in the compile time.

Since everything works well today, this is not very urgent to fix.

[fregante]

Then the service worker can use import or export statements, not importScripts.

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.

[fregante]

dynamic import

That didn't seem to work for me 🤷‍♂️ I got the same error as before

Changing it to import statement fixed it.

---

So technically now I'm using a native ES background worker in webpack-target-webextension. This issue is fixed? Maybe it just needs some documentation?

[Jack-Works]

Native ES service worker works, dynamic import does not.

While using this plugin, compiled ES modules (including dynamic import) work after bundling, loading by importScritps. Native ES service worker does not work with this plugin currently (the screenshot you gave).

[Jack-Works]

I just took another look of this. This is not possible until there is ES Module support in content script if you want to share any chunks.

[fregante]

e is ES Module support in content script

I think you meant "in background workers" right?

[Jack-Works]

e is ES Module support in content script

I think you meant "in background workers" right?

No, to share chunks between the background and content script, they must use the format that both environments support. Now ES Module is only supported in the background worker and not supported in the content script, so there is no meaning in investigating this.

[fregante]

What do you mean? I definitely am using both static and dynamic ESM in content scripts:

https://robwu.nl/crxviewer/?crx=https%3A%2F%2Fchromewebstore.google.com%2Fdetail%2Frefined-github%2Fhlepfoohegkhhmjieoechaddaejaokhf%3Fhl%3Den

See content-script.js.

There are some tricks though:

• you need to use import(chrome.runtime.getURL('actual-content-script.js')) in your entry point in order to later be able to use import statements
• all JS files need to be in web_accessible_resources

[Jack-Works]

hmm wait you're right, an extra file will be enough to load ESM in content script.