85

I am using ES2015 Import / Export modules.

In my worker file, when I try to import functions like I normally do:

worker.js

import { a, b, c } from "./abc.js";

I get the error: SyntaxError: import declarations may only appear at top level of a module

As I am exporting functions in my module 'abc.js', I am not sure how to use them using the old (& apparently on its way out) syntax:

self.importScripts( "/app/abc.js" );

So, my question is, how do we use the new import module syntax with workers?

Second question is, what does importScripts import into when it imports from a module in where is there is no global object parent being exported?

Improve this question

6 Answers 6

Reset to default
106

ES2015 modules in Workers are available in Safari and in Chromium browsers.

If other browsers / versions are your target, you still need to use importScripts().

When available, you create a module-worker like this:

new Worker("worker.js", { type: "module" });

See: https://html.spec.whatwg.org/multipage/workers.html#module-worker-example

These are the bug-reports for each browser:

  • Firefox:
    Workers: Available since version 114 ✔️
    Service Workers: in development 🏴
  • Chromium Browsers:
    Dedicated Workers: Available since version 80 ✔️
    Shared Workers: Available since version 83 ✔️
    Service Workers: Available since version 91 ✔️
  • Webkit:
    Safari Desktop: Available since Safari 14.1 ✔️
    Safari Mobile (iOS): Available since Safari 15 ✔️

The relevant Can I Use live compatibility data: https://caniuse.com/?search=module%20worker

Improve this answer
Sign up to request clarification or add additional context in comments.

8 Comments

How to know when it will be supported?
See my updated Answer. Chromium is actively developing it.
Ah, so only the new Worker(..) needs to specify "module". The actual worker code can have import/export as normal. Is this right? Sounds like node's .mjs :)
It’ll be shipped with Chromium 80 and Chrome 80 is planned to be stable on February 4, 2020. Alright…….
Note: If you have a dependency that forcibly uses importScripts, then you can replace self.importScripts with a function that does a synchronous XHR and self.eval() as a polyfill.
|
12

Chrome 80 has shipped module workers in February 2020 (and Chrome 82 will ship modules for shared workers). Firefox/Safari do not support those features for now: tests

You may want to use import-from-worker lib to do the heavy lifting for you (for now, you need to check the support for modules in workers and do the fallback by yourself).

Improve this answer

1 Comment

twitter.com/DasSurma/status/1392799265567694851
4

ES Modules in workers are already available in Chrome, enabling Experimental Web Platform Features, using the proper flag when launching chrome:

chrome.exe --enable-experimental-web-platform-features

This is the syntax you need to use to load the worker script as a module :

new Worker( 'my-worker.js', { type : 'module' } );

This feature has been in development for almost ayear, and should be available soon, without the need of special flags, however, there is no official release date yet.

Improve this answer

1 Comment

Also instead starting with a flag there option for that in chrome://flags/ then search for Experimental Web Platform features or something like that
4

One solution is to use rollup to generate an IIFE from your worker as follows:

//worker.js import { MyModule } from 'my-module.js' onconnect = async (e) => { var port = e.ports[0]; MyModule.func() port.onmessage = (e) => { port.postMessage("Hi App"); } } //rollup config export default [ { 'input': 'worker.js', 'output': { 'file': 'dist/worker.js', 'format': 'iife' }, }, ] //dist/worker.js (rollup output) (function () { 'use strict'; //MyModule code here, generated by rollup MyModule.func() onconnect = async (e) => { var port = e.ports[0]; port.onmessage = (e) => { port.postMessage("Hi App"); }; }; }()); //main app const worker = new SharedWorker("/dist/worker.js"); worker.port.onmessage = (e) => { console.log('Message received from worker: ' + e.data); } worker.port.postMessage("Hi worker");

Essentially rolllup is doing the work that browsers should be doing. This is working well for me. Of course the code size is increased because the module code is getting copied into worker as well. But it is still DRY as the code is being generated by rollup.

Improve this answer

Comments

2

Many answers on this page have been deprecated; browsers instead have implemented importScripts(): WorkerGlobalScope: importScripts() method

Within a worker:

importScripts("my/cool/lib.js", "/my/other/cool/lib.js");

💡Prefer to use hard links to avoid headaches.

Improve this answer

Comments

-3

for me assigning to self. worked well. I've put import to another js file: abcImported.js

import { a, b, c } from "./abc.js"; export { a, b, c };

and in the service worker: 

self.a = require('abcImported.js').a; self.b = require('abcImported.js').b;

in this way, it is accessible inside the worker. (tested in chrome)

Improve this answer

4 Comments

Where are you getting require from?
I think this is another (insane!) case where workflow has modified "require" into a solution that works. Rollup? or more likely Webpack?
Yep, webpack. In my case it was rails applications which uses webpacker gem which uses webpack :)
Is abcImported.js a file hosted separately?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.