Feature Request
Internally, there's lots of places where WXT makes assumptions about the strings people are using for the --browser flag. Common examples would be "chrome", "firefox", "safari", "opera", "brave", etc, but it can be anything.
The assumptions WXT makes are related to how it resolves specific things, like manifest options, that may only be supported by chrome or firefox or safari. But what if someone has both an "ios" target and a "safari" target? Any logic that checks wxt.config.browser === "safari" will miss ios, when ideally "ios" should result in the same manifest as "safari".
So WXT needs a way to resolve which browser to generate things for - but that is different from which label you're building under.
Proposing a few changes to the current ResolvedConfig and InlineConfig types:
- Keep using
InlineConfig#browser (--browser CLI flag) for the output directory, import.meta.env.BROWSER and related runtime constants
- Introduce
InlineConfig#targetBrowserMap: Record<TargetBrowser, " that has a good default, but that can be customized by projects to map different --browser strings to the actual browser the extension will run in
- Introduce
ResolvedConfig.actualBrowser: "chromium" | "firefox" | "safari" which is used when generating manifest or other browser-specific code. I'm not sure if opera (or future browsers/forks) but it could be added to the union in the future, and we'd have have to update the checks.
Is your feature request related to a bug?
I thought this was already implemented, but I must have done it somewhere else, never ported into WXT.
Discussion here: #2581 (comment)
What are the alternatives?
AFAIK there is no way to "know" if a --browser is chrome or not without a way to map custom values to their actual browser.
Additional context
Related to #2301
Feature Request
Internally, there's lots of places where WXT makes assumptions about the strings people are using for the
--browserflag. Common examples would be "chrome", "firefox", "safari", "opera", "brave", etc, but it can be anything.The assumptions WXT makes are related to how it resolves specific things, like manifest options, that may only be supported by chrome or firefox or safari. But what if someone has both an "ios" target and a "safari" target? Any logic that checks
wxt.config.browser === "safari"will miss ios, when ideally "ios" should result in the same manifest as "safari".So WXT needs a way to resolve which browser to generate things for - but that is different from which label you're building under.
Proposing a few changes to the current
ResolvedConfigandInlineConfigtypes:InlineConfig#browser(--browserCLI flag) for the output directory,import.meta.env.BROWSERand related runtime constantsInlineConfig#targetBrowserMap: Record<TargetBrowser, "that has a good default, but that can be customized by projects to map different--browserstrings to the actual browser the extension will run inResolvedConfig.actualBrowser: "chromium" | "firefox" | "safari"which is used when generating manifest or other browser-specific code. I'm not sure if opera (or future browsers/forks) but it could be added to the union in the future, and we'd have have to update the checks.Is your feature request related to a bug?
I thought this was already implemented, but I must have done it somewhere else, never ported into WXT.
Discussion here: #2581 (comment)
What are the alternatives?
AFAIK there is no way to "know" if a
--browseris chrome or not without a way to map custom values to their actual browser.Additional context
Related to #2301