In the browser, what changes when you construct a Web Worker as `new Worker(url, { type: 'module' })` instead of the default `new Worker(url)`, and why does `importScripts()` stop working in the module case?

## Two script types, one constructor `Worker` takes a second argument: `new Worker(scriptURL, options)`, where the options are `type`, `name` and `credentials`. `type` is `'classic'` by default, which is why plain `new Worker('/w.js')` gives you a classic worker. The choice decides how the browser *evaluates* the entry script, and that ripples through everything else about how the worker loads code. ## The classic worker A classic worker script is evaluated the way an old-style `<script>` is: one flat global scope, no strict mode unless you write `'use strict'`, top-level `var` and function declarations landing on the worker global. Dependencies come from `importScripts()`, which exists only in classic workers: ```js // worker.js — classic (the default) importScripts('/vendor/tokenizer.js', '/vendor/stemmer.js'); // both scripts have now been fetched, run to completion, and // their globals are visible here self.onmessage = (event) => { const tokens = tokenize(event.data); self.postMessage(stem(tokens)); }; ``` Three properties matter. It is **synchronous** — the call blocks the worker thread until each script is fetched and executed, which is tolerable off the main thread but still stalls that worker. It takes **multiple URLs** and runs them in argument order. And it is **not scoped**: everything the loaded scripts declare goes into the same global, so name collisions are yours to manage. It is also allowed to load cross-origin scripts, unlike the worker's own entry URL, which must be same-origin. ## The module worker ```js // worker.js — module import { tokenize } from './tokenize.js'; import { stem } from './stem.js'; self.onmessage = async (event) => { const { normalise } = await import('./normalise.js'); // dynamic import works too self.postMessage(stem(tokenize(normalise(event.data)))); }; ``` Constructed as `new Worker('/worker.js', { type: 'module' })`. Now the entry point is a module: it is parsed, its imports are resolved and fetched, the whole graph is instantiated, and only then is any of it evaluated. Each module has its own scope; nothing leaks to the global unless you put it there explicitly. Strict mode is on, so a stray undeclared assignment throws instead of creating a global. Dynamic `import()` is available for lazily pulling in a rarely used code path. `importScripts()` is deliberately absent here. Its whole contract — stop, fetch, run, continue — contradicts the module loader's contract, where the dependency graph is resolved up front and evaluation is ordered by the loader. Calling it in a module worker throws a `TypeError`. That is the single most common migration surprise: someone flips `type: 'module'` on an existing worker and it dies on the first line. The `credentials` option (`'omit'`, `'same-origin'`, `'include'`) also only applies to module workers; it controls how the module scripts are fetched. ## The bundler URL pattern Worker scripts are separate files, so they need URLs that survive bundling and hashing. Modern bundlers (Vite, webpack 5 and friends) statically recognise this exact literal shape: ```js const worker = new Worker( new URL('./search.worker.js', import.meta.url), { type: 'module' } ); ``` The bundler sees `new URL(<string literal>, import.meta.url)` inside a `new Worker(...)` call, emits the worker as its own chunk, and rewrites the URL to the hashed output path. Break the pattern — compute the path in a variable, pass a bare string, wrap the construction in a helper that receives the URL as an argument — and the bundler can no longer see it, so you ship a URL that 404s in production while working perfectly in dev. ## Choosing For new code, module workers are the better default: real scoping, static analysis, tree shaking, and the same import syntax as the rest of your app. Reach for a classic worker when you must load a third-party script that only exists as a global-assigning bundle, when you construct the worker from a `blob:` URL built at runtime, or when you are targeting an environment where you cannot rely on module worker support. As of 2025–2026, module workers are supported across all current major browsers; Firefox was the last to ship them, in Firefox 114 (2023). If you must support older builds, either stay classic or ship a fallback that catches the constructor failure and retries with a bundled classic script.