defineContentScript doesn't work with world: "MAIN"

[aklinker1]

Describe the bug

Main world doesn't support browser APIs, but defineContentScript imports the polyfill because of ContentScriptContext.

Because these content scripts need sandboxed and can't have a ctx, WXT should export a separate function, defineMainWorldContentScript, from wxt/sandbox module, which doesn't include the webextension-polyfill, and thus avoids the error.

Alternatively, we could try and define globals inside content-script-entrypoint.ts and tree-shake the polyfill out. Not sure if that's possible though.

Or a third option, if the content script runs in the main world, alias webextension-polyfill to a noop module, similar to how we alias it for experimental.includeWebextensionPolyfill.

To Reproduce

Archive.zip

pnpm dev

Then go to https://google.com and open the console.

Expected behavior

Main world content scripts shouldn't import the polyfill and the script shouldn't crash.

Environment

  System:
    OS: macOS 13.4.1
    CPU: (8) arm64 Apple M1 Pro
    Memory: 3.02 GB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.16.1 - ~/.asdf/installs/nodejs/18.16.1/bin/node
    Yarn: 1.22.19 - ~/.asdf/installs/nodejs/18.16.1/bin/yarn
    npm: 9.5.1 - ~/.asdf/plugins/nodejs/shims/npm
    pnpm: 8.9.0 - ~/.asdf/installs/nodejs/18.16.1/bin/pnpm
  Browsers:
    Chrome: 120.0.6099.71
    Safari: 16.5.2
  npmPackages:
    wxt: ^0.11.0 => 0.11.2 

Additional context

CC @AndrewWalsh

[aklinker1]

Between the two options, there are pros and cons.

1. createMainWorldContentScript
   • Pros:
     • Simple types
     • Doesn't mix sandboxed content with non-sandboxed content
   • Cons:
     • Yet another helper function for people to learn
     • Makes a second way of defining content scripts
     • More complex than just setting world: "MAIN"
2. Exclude the polyfill for main world scripts
   • Pros:
     • No breaking changes
     • Works as expected, no extra fucntions
   • Cons:
     • Complex internal implementation
     • Types will be more complex, making the API reference harder to read

I think I'll go with the second approach. I don't want to create variants on variants of the different helper functions (also see #273).