[devtechedge]

Overview

Fixes #2588.

Right now every build-time browser check compares wxt.config.browser against a literal like "firefox" or "safari". An ios build therefore misses every Safari check and generates the wrong manifest, even though it runs in Safari.

This PR implements the three changes proposed in the issue:

1. InlineConfig#browser keeps working exactly as before: it still drives the output directory template, import.meta.env.BROWSER, the CHROME/FIREFOX/SAFARI/EDGE/OPERA env constants, the zip artifact name, and browser launching. Nothing changes for existing labels.

2. InlineConfig#targetBrowserMap maps --browser strings to the actual browser. It defaults to:

   --browser value	Actual browser
   chrome, edge, brave, opera, chromium	chromium
   firefox	firefox
   safari, ios	safari

   Unknown labels are not mapped to anything by default. They resolve to themselves until the project adds an entry for them, so their behavior is unchanged.

3. ResolvedConfig#actualBrowser: "chromium" | "firefox" | "safari" is resolved through that map and is now used for the manifest generation checks: use_dynamic_url (introduced in fix: don't set use_dynamic_url on browsers that don't support it #2581), MV2/MV3 key stripping, background/background scripts, version_name, browser_style/chrome_style, options_ui in Safari, side panels, and the Firefox warnings. The default manifest version (MV2 for Firefox and Safari) is also resolved off the actual browser now, so an ios build gets the same manifest as a safari build.

The per-entrypoint include/exclude lists and per-browser entrypoint options still key off the raw --browser label, since those are user-authored values keyed by label.

Manual Testing

• Added mapping tests to resolve-config.test.ts: every default mapping resolves correctly, a custom targetBrowserMap entry wins over the defaults, unknown labels resolve to themselves, actualBrowser appears on the resolved config, and the output directory still uses the raw label while the default manifest version keys off the actual browser.
• Added a manifest test proving an ios build with actualBrowser: "safari" skips the Chrome-only use_dynamic_url field.
• Verified fail-before/pass-after: with only the source changes stashed, the new tests fail (11 config resolution assertions plus the manifest assertion); with them restored, all pass.
• bun run check passes at the repo root, bun run test passes in packages/wxt (559 tests, one pre-existing flaky e2e that passes on re-run and is unrelated to this change).

Related Issue

This PR closes #2588. Related discussion: #2581 (comment) and #2301.

[netlify]

✅ Deploy Preview for creative-fairy-df92c4 ready!

Name	Link
🔨 Latest commit	a332c76
🔍 Latest deploy log	https://app.netlify.com/projects/creative-fairy-df92c4/deploys/6aa7397e9ab44b00085f0161
😎 Deploy Preview	https://deploy-preview-2622--creative-fairy-df92c4.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

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

[devtechedge]

Hi - gentle follow-up on the actual-browser resolution work whenever it fits your queue.

Builds keyed as ios (and other Chromium/Safari aliases) were missing browser-specific manifest checks because those compared wxt.config.browser to literals like "safari" (Fixes #2588).

This adds InlineConfig#targetBrowserMap and ResolvedConfig#actualBrowser (chromium | firefox | safari) in packages/wxt/src/types.ts / resolve-config.ts / target-browser.ts, and switches the manifest path in packages/wxt/src/core/utils/manifest.ts to actualBrowser while output dirs, import.meta.env constants, zip names, and launching stay on the raw label.

Tests in resolve-config.test.ts and manifest.test.ts cover the default map, custom overrides, unknown labels resolving to themselves, and the Safari/iOS manifest behavior (12 new assertions; local bun run check plus packages/wxt vitest were green here).

Validate / pkg.pr.new / Check PR Title are still waiting on first-contribution approval; Netlify preview and a few pages checks already completed successfully.

Happy to reshape the default map, tighten types, or add another fixture if that would make review easier.

No rush at all - still ready from my end whenever bandwidth allows.

[PatrykKuniczak]

@devtechedge Closed by mistake or you don't want to go on with that?

[devtechedge]

Closed by mistake, sorry about that! The PR closed when I cleaned up my forks. I'd still love to get this in. I'm rebasing it onto current main and will open a fresh PR shortly that links back here. If you have thoughts on the targetBrowserMap / actualBrowser API in the meantime, I'm happy to adjust.

[devtechedge]

Fresh PR is up: #2687 (rebased onto current main, all tests passing).

[PatrykKuniczak]

Closed by mistake, sorry about that! The PR closed when I cleaned up my forks. I'd still love to get this in. I'm rebasing it onto current main and will open a fresh PR shortly that links back here. If you have thoughts on the targetBrowserMap / actualBrowser API in the meantime, I'm happy to adjust.

No problem, i'll take a look on that, when i'll find some time, thanks :)

[devtechedge]

Thanks Patryk, I appreciate you taking the time.

No rush at all, whenever it works for you is great.

Just to make it easy, the work is now in #2687, rebased onto current main with all tests passing locally.

If any part of the targetBrowserMap / actualBrowser shape feels awkward when you look at it, I'm glad to adjust it or split it into smaller pieces.

Happy to walk through the design decisions or add more fixtures if that helps.

Looking forward to your thoughts whenever you get to it.

[PatrykKuniczak]

Thanks Patryk, I appreciate you taking the time.

No rush at all, whenever it works for you is great.

Just to make it easy, the work is now in #2687, rebased onto current main with all tests passing locally.

If any part of the targetBrowserMap / actualBrowser shape feels awkward when you look at it, I'm glad to adjust it or split it into smaller pieces.

Happy to walk through the design decisions or add more fixtures if that helps.

Looking forward to your thoughts whenever you get to it.

I've been going through notification mailbox today.
I don't have mood and energy, tough period of life, but i'll take a look on that this week, because this project fueling me, and i'm happy we have more and more contributors 😸