feat!: ESM background support

[aklinker1]

Adding type: "module" to the background script definition will cause it to be included in the ESM build along side any UIs. This speeds up development, reduces bundle size, and adds support things like WASM, which requires ES modules to load (this will address #392).

Note that even if we're using ESM for the background, we need to restart the service worker by reloading the entire extension (see #53 for more details). Since HMR doesn't really do anything for the background, so I'm not adding support for that.

Todo

• Include in UI multi-page build when type=module
• Double check that type=module is ignored for MV2
• Fix dev mode reload messages
• Add tests

[netlify]

✅ Deploy Preview for creative-fairy-df92c4 ready!

Name	Link
🔨 Latest commit	d490019
🔍 Latest deploy log	https://app.netlify.com/sites/creative-fairy-df92c4/deploys/65bd14a5ad00510008a2c8d3
😎 Deploy Preview	https://deploy-preview-398--creative-fairy-df92c4.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codecov]

Codecov Report

Attention: 30 lines in your changes are missing coverage. Please review.

Comparison is base (41fa320) 80.30% compared to head (d490019) 80.35%.

Files	Patch %	Lines
src/core/create-server.ts	3.33%	29 Missing ⚠️
src/core/builders/vite/index.ts	96.55%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #398      +/-   ##
==========================================
+ Coverage   80.30%   80.35%   +0.04%     
==========================================
  Files         107      107              
  Lines        7728     7761      +33     
  Branches      695      701       +6     
==========================================
+ Hits         6206     6236      +30     
- Misses       1506     1509       +3     
  Partials       16       16              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[aklinker1]

Breaking change to the build output format.

Before:

.output/
  <target>/
    chunks/
      popup-<hash>.js
    popup.html

After:

.output/
  <target>/
    popup.html
    popup.js

[aklinker1]

This change ensures the ESM background entrypoint (a JS file, not HTML), is output to the root of the build directory as well, just like the non-ESM background.

[lionelhorn]

@aklinker1 Is it possible to control the output path using wxt.config.ts?

To have one build for dev and prod.
So when I build for dev it doesn't overwrite previously built one for prod.

.output/
  dev-chrome-mv3/
    chunks/
      popup-<hash>.js
    popup.html

And also

.output/
  prod-chrome-mv3/
    chunks/
      popup-<hash>.js
    popup.html

[aklinker1]

@lionelhorn In a hacky way, yes. You could set an environment variable, and reference it in the wxt.config.ts file while setting the outDir. WXT doesn't provide any options for changing the target directories inside the output directory.

DEV=true wxt
wxt build

// wxt.config.ts
import { defineConfig } from 'wxt';

export default defineConfig({
  outDir: process.env.DEV === "true" ? ".output/.dev" : ".output"
});

This would give you something like:

.output/
   .dev/
     chrome-mv3/
     firefox-mv2/
   chrome-mv3/
   firefox-mv2/