Importing a CommonJS node_module in a custom service worker turns it into an ES module

[kgroat]

I've discovered that creating a custom service worker using the injectManifest strategy can lead to an issue when importing a node_module that is in the CommonJS format. Specifically, the service worker will end up as an ES module, with an export default, which will result in an error when registered in the browser. The built asset will look something like this:

var t = (l, o) => () => (o || l((o = { exports: {} }).exports, o), o.exports);
var _ = t((r, e) => {
  // Your compiled code here
});
export default _();

I've created this minimal reproduction case here.

I've discovered that adding this to the config gets rid of the default export, but I'm not sure if it has other side-effects:

VitePWA({
  // the rest of your config up here...

  injectManifest: {
    rollupFormat: 'iife'
  }
})

[userquin]

It seems a problem with esbuild: vitejs/vite#15379

EDIT: SvelteKit now builds the service worker using also iife format.

[Rich-Harris]

SvelteKit now builds the service worker using also iife format.

FYI we're reverting that change in favour of telling esbuild that the filename ends with .mjs sveltejs/kit#11400

[userquin]

@Rich-Harris good to know it, thx

How about .mts when using TS?

[Rich-Harris]

that wouldn't make sense — this is the output filename. it's purely a signal to esbuild that prevents it from erroneously adding an unwanted export declaration

[userquin]

yeah, forgot it