wxt-dev/wxt

Feature Request Let's add web-ext as devDeps for wxt-demo, analytics and maybe for others. To be able to enable dev mode after browser was opened after wxt run. I know @aklinker1 decided to remove web-ext from core and i think it's good idea. But for dev purposes(our as maintainers), it's good to use it, to avoid enabling developer mode each time. And maybe it's possible to pin plugin on tool bar, somebody who's pick this task, need to figure it out. If it isn't, maybe that's possible to add it to web-ext, because guys are active. Maybe even i'll implement it for upstream and then, we'll be able to use it there. It can drastically improve PR checking process and bug finding for core wxt package and rest packages.

Noticed this in #2459, but consola is using it's basic formatter in the GIF... so it's logging [log] and [info] instead of no prefix and i, respectively. https://github.com/wxt-dev/wxt/blob/e5ef936/docs/assets/init-demo.gif This is probably because the GIF is generated by the github action, and consola sees it's a CI environment, so it doesn't use the pretty formatter, uses basic instead. Not sure how to override this, but I'd prefer we use the pretty logger for the GIF

Describe the bug In MV3 development mode, WXT dynamically registers content scripts from the background service worker instead of putting them in manifest.content_scripts. When a content script is defined with matchOriginAsFallback: true, the production manifest preserves the option as match_origin_as_fallback: true, but the dev-mode dynamic registration drops it. As a result, dev mode behaves differently from production for about:blank / about:srcdoc iframes that depend on origin fallback. Reproduction Define a content script like this: export default defineContentScript({ matches: ["*://*/*", "file:///*"], allFrames: true, matchAboutBlank: true, matchOriginAsFallback: true, async main() { // ... }, }) Run WXT in MV3 dev mode: wxt -b edge Then inspect the registered content scripts from the extension service worker: await chrome.scripting.getRegisteredContentScripts() Actual behavior The dynamically registered content script has matchOriginAsFallback: false: { "id":

Feature Request Add a new registration: 'optional' option for content scripts that moves their matches into optional_host_permissions instead of host_permissions, and registers them dynamically via browser.scripting.registerContentScripts() at runtime. Currently, registration: 'runtime' moves matches to host_permissions, which still triggers Chrome's permission escalation dialog when new hosts are added on extension update (disabling the extension until the user re-accepts). Extensions that want to support new hosts without disabling need to use optional_host_permissions instead. Proposed API: export default defineContentScript({ matches: ['https://my-app.com/*'], registration: 'optional', // ... }); Behavior: Strip the content script's matches from manifest.json content_scripts Add them to optional_host_permissions instead of host_permissions Would be nice if this was deduped if user already had urls in optional_host_permissions. example if I had *.app.com in optional_h

Describe the bug Setup // wxt.config.ts export default defineConfig({ zip: { includeSources: ['entrypoints/**'], }, }) Repo tree: entrypoints/foo.ts entrypoints/bar.js cache/secrets/abc super-secret-file .gitignore Expected behavior $ wxt zip:firefox $ zipinfo .output/*sources.zip entrypoints/foo.ts entrypoints/bar.js Current non-intuitive, dangerously leaky behavior $ wxt zip:firefox $ zipinfo .output/*sources.zip entrypoints/foo.ts entrypoints/bar.js cache/secrets/abc super-secret-file Hacky workaroud I should not have to do this, but that's how I worked around this bug: export default defineConfig({ zip: { excludeSources: ['**'], includeSources: ['entrypoints/**'], }, }) I'll point out that this usually not how an allowlist/denylist behaves. The "accepted", safe, intuitive behavior is the following: Nothing configured: default behavior, today "Hidden files, node_modules, and tests are ignored". I'd personally vote for a more advanced "respect .Xignore" support