Feat/1101 support iife content scripts

[salmin89]

Hey guys!

Full disclosure:

I used Agents to heavily assist with this PR. This feature is something we've needed at my company for a while, but I never had enough time to learn CrxJS enough to be able to it without help from AI. My strategy was to write tests to make sure we didn't break any existing functionality.

This feature would solve a number of open issues (some of which would need to accept the iife lifestyle)
#1102
#1101
#1152
#1119

The following below is what the AI generated to describe this PR.

---

feat: Add IIFE content script bundling

Summary

This PR adds support for bundling content scripts as self-contained IIFE (Immediately Invoked Function Expression) files. Content scripts named with the .iife.ts extension are automatically detected and built as single files with all dependencies inlined.

Motivation

When injecting content scripts into the MAIN world using chrome.scripting.executeScript or chrome.scripting.registerContentScripts, ES modules are not supported. This requires content scripts to be bundled as IIFE files with no external imports.

Previously, developers had to manually configure separate build steps or use workarounds. This PR adds first-class support for IIFE content scripts with zero configuration.

Usage

1. Manifest-declared content scripts

Name your content script with .iife.ts extension:

src/content/injected.iife.ts

import { someHelper } from './utils'

console.log('Running in MAIN world!', someHelper())

manifest.config.ts

export default defineManifest({
  content_scripts: [
    {
      js: ['src/content/injected.iife.ts'],
      matches: ['https://*/*'],
      world: 'MAIN',
    },
  ],
})

2. Dynamic content scripts (chrome.scripting API)

src/background.ts

import scriptPath from './content/injected.iife.ts?script'

chrome.action.onClicked.addListener((tab) => {
  chrome.scripting.executeScript({
    target: { tabId: tab.id },
    world: 'MAIN',
    files: [scriptPath],
  })
})

Output

Regular content script (main.ts):

• Uses loader pattern with code-splitting
• Output: assets/main.ts-loader-xxx.js + chunks

IIFE content script (main.iife.ts):

• Single self-contained file with all imports inlined
• Output: src/content/main.iife.js

// Built output of .iife.ts file
(function(){"use strict";function helper(){return"inlined"}console.log("Running!",helper())})();

Benefits

• Zero configuration - Just name your file .iife.ts
• All imports inlined - No external dependencies or dynamic imports
• MAIN world compatible - Works with chrome.scripting.executeScript
• Works with ?script imports - Auto-detected for dynamic content scripts

Trade-offs

• No code sharing between IIFE content scripts (each is fully self-contained)
• Separate build step per IIFE script (slightly longer build time)

Testing

• Added unit tests for isIifeContentScript filename detection (10 tests)
• Added E2E tests for build output verification
• Added E2E tests for dev server compatibility

[changeset-bot]

🦋 Changeset detected

Latest commit: e3c75f9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@crxjs/vite-plugin	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Toumash]

hm whats the difference #1101 / #1102 other than .iife.js vs ?iife? @salmin89

[salmin89]

I'd love to see what @jacksteamdev thinks about this solution

[salmin89]

hm whats the difference #1101 / #1102 other than .iife.js vs ?iife? @salmin89

Initially when I tested 1102 it didn't do what I needed it to do. I see that you ended up updating the PR and got it working (I missed the update).

I would say that this PR does the same thing as #1102 does, but also adds support for IIFE in the manifest (by naming .iife).

---

I just added a comment to your PR while testing it out:
#1102 (comment)

[Toumash]

lgtm