Config file lacks some features or I just don't know how to achieve them?

[dvlden]

Are any of these possible?

1. I'd like to disable webextension-polyfill
2. I'd like to be able to use chrome instead of browser
3. I'd like to disable whatever these are (screenshot sample) that get bundled in the output files
4. I'd like to be able to define what are external libraries or provide a pattern (e.g. all node_module imports), so that it exclude those from the entry points and instead chunk them in vendor files or similar and then import into entry point where belongs

[aklinker1]

1. I'd like to disable webextension-polyfill

One of WXT's main goals is to make it easy to create web extensions for all browsers, including firefox, which is why it uses webextension-polyfill. The polyfill also make the MV2 and MV3 chrome APIs consistent. WXT uses these consistent, cross-browser APIs provided by the polyfill to make improvements behind the scenes in both dev mode and production builds. Disabling the polyfill would mean I have to write the same code in 3 different ways, which would be a large maintenance burden.

So I don't plan on adding this.

[aklinker1]

2. I'd like to be able to use chrome instead of browser

You can do that! Nothing is stopping you from using chrome in your project's code. If you're using typescript, you can install types for the chrome global and it will just work, since chrome is just a global variable the browser provides, no need to import it. Haven't tried this out personally, so there may be a few more steps needed. Would be a good thing to add an example for... 👀

You won't be able to remove the polyfill from the final bundles because it's used internally by WXT in production, so it will always be included in your final bundle.

I would highly recommend using browser though. Several reasons:

1. If you're familiar with Chrome's MV3 promise API, it's the exact same thing, but using browser instead of chrome
2. Works across all browsers with zero configuration in WXT. No code changes if you ever decide to ship to Firefox or Safari in the future
3. WXT modifies the browser variable's type to add type-safety to operations like browser.i18n.getMessage and browser.runtime.getURL, and I plan on making more type improvements in the future
4. browser is the standard for WXT projects. For someone who's familiar with the framework, it will be easier for them to pick up and contribute to a project following the standard

Obviously though, you're free to use chrome for your project if browser still doesn't make sense.

[aklinker1]

3. I'd like to disable whatever these are (screenshot sample) that get bundled in the output files

I have no idea referencing in your screenshot, it's to zoomed in to tell. Is this a content script, background, or chunk? Also not sure if this is a production build or a dev build - WXT adds code to each, but the code it adds is different for each mode.

Can you share the actual code, maybe just copy-paste the actual statements you're curious about?

Personally, I don't worry too much about the size of a web extensions. All the files are loaded locally from the users file system, so it's OK if they're not perfectly optimized, unlike the web. Of course, WXT shouldn't include unnecessary bloat or malicious code, which it doesn't.

If you want to review what WXT adds to your code, here are the links. Your entrypoint files are imported as import definition from 'virtual:...' at the top of each of these files.

• Background: https://github.com/wxt-dev/wxt/blob/main/src/virtual/background-entrypoint.ts
• Content Scripts: https://github.com/wxt-dev/wxt/blob/main/src/virtual/content-script-entrypoint.ts
• Unlisted Scripts: https://github.com/wxt-dev/wxt/blob/main/src/virtual/unlisted-script-entrypoint.ts

[dvlden]

I attempted to create tiny extension bundle with Vite yesterday.
Since wxt config accepts additional configuration for Vite itself, I assume that this can be added to get rid of that bundled code:

Vite Docs

build: {
  modulePreload: {
    polyfill: false,
  },
}

[aklinker1]

Yes, you can provide this through the vite config option in your wxt.config.ts file

[aklinker1]

4. I'd like to be able to define what are external libraries or provide a pattern (e.g. all node_module imports), so that it exclude those from the entry points and instead chunk them in vendor files or similar and then import into entry point where belongs

Big question with a long answer lol. TLDR: Reusing chunks like this across all entrypoints, while maybe possible from a technical perspective, has major limitations, would be very fragile, and would complicate the build process. So no, this is not something that is realistically possible.

More details

So basically you want to enable code-splitting across all entrypoints (HTML pages, background, and content scripts) to share code between everything. While this is possible, it has some limitations, limitations I've decided are to great to support at this time. Currently, all HTML pages are built in a single step, and do share "chunks" of code used between them. These often include packages from node_modules, like you mention, but also any utilities used on multiple pages. So HTML files are already doing what you want.

The background script is all bundled individually. So if you use code or libraries that are also used in HTML pages, they will be duplicated inside your background script. MV2 background pages do not support CJS or ESM formats, so MV2 backgrounds script have to be self contained and bundled individually. MV3 supports ESM service workers and could reuse the chunks generated by the HTML pages, but unfortunately, Rollup's chunking algorithm doesn't take into account that the background script doesn't have a window object. So if we were to reuse chunks, UI packages often have side-effects use the window as soon as they're imported, and cause the background to crash. So keeping it self contained and bundled separately prevents these types of crashes.

As for content scripts, they do not support ESM, and thus cannot reuse chunks from the rest of the build, just like the background. There is a "hack" to use ESM in content scripts, but it has downsides. You could use a dynamic await import(...) statement to load an ESM file from your content script and put all your logic in there. However, this has two downsides. First, you lose access to the browser or chrome globals because the ESM script runs in the page's context, not in the content script's context (it's "isolated world"). Second, since dynamic imports are async, this will ignore your runs_at configuration. For these two reasons, WXT does not support this.

So to summarize. If you have an extension with two HTML pages (let's say a popup and options page), a background script, and one content script, any shared code will be present 3 times in your final bundle. You can verify this using wxt build --analyze, and looking at the stats.html file that is generated. It will break down everything that is inside the output directory, what is reused and where.

[dvlden]

I was considering to do this for popup only, as that can be ESM in all browser. Assuming?
Managed to achieve it with Vite, through their rollupOptions configuration.

manualChunks: {
  vendor: ['@arrow-js/core'],
},

[aklinker1]

Yes, that would be the way to go.

[dvlden]

Thanks for all of the feedback here. It means a lot!

I am bundle-phobic, did not know that it's irrelevant for the browser extension to worry about the size. That's why I was aiming to get rid of everything (all polyfills) and even forget about the frameworks that I enjoy working with, just to gain the minimal bundle as possible.

Found out about @arrow-js and figured why not. It gives me Proxy/Reflection with nice functions (similar to Vue), while not requiring any build step.

Aside, I also wanted to make a tiny wrapper that would either use chrome or browser and only support functions that I actually need for my extension.

But now with your information, I think I should just go with wxt and Vue, as I initially wanted to and keep webextension-polyfill, since I do intend do support all browsers.

I am kind of worried on one side here. I see that you are actively developing wxt and I really like it, but I am not sure if it's a long term project or will be short term, where eventually after some time I'll have to rewrite my extension again with some other cool toolkit.

[aklinker1]

I had not heard of arrow-js before, seems like a really cool project! You can definitely create a vanilla, no build step web extension, but the downsides there is that you won't be able to use NPM modules and the dev experience will be much slower without a custom dev mode. So if you want those, a bundler/framework is the only choice.

I am kind of worried on one side here. I see that you are actively developing wxt and I really like it, but I am not sure if it's a long term project or will be short term, where eventually after some time I'll have to rewrite my extension again with some other cool toolkit.

A valid concern. I have another project for building web extensions, vite-plugin-web-extension, which has been around for 2-3 years and is basically in maintenance mode since WXT is ready for production.

I maintain around 6 extensions, both for work and for pleasure, so I started making build tools for web extensions to make my life easier, because it sucked 3-4 years ago lol. Just this morning I merged the PR to convert my first work extension to WXT. So I'm committed to maintaining it as long as I work at my current job and as long as I maintain my personal extensions, Github Better Line Counts and Anime Skip Player, which I don't see stopping any time soon.

WXT is getting to the point of being feature complete for everything I need and everything others have needed from vite-plugin-web-extension over the past 2-3 years, so I will be slowing down feature development and have others contribute if they want to add features.

That's my long term plan for WXT.

[dvlden]

Fantastic. Thank you for your input.

I saw vite-plugin-web-extension being used on multiple repositories, but I read that this will be successor and I did not care to look at the latter. It was very hard to find, but I found it.

This is my extension that I plan on rewriting, if you are curious:
UltraWideo

Interesting extension list of yours.
I'm happy to hear that and I'll try to contribute with things that I find interesting and also sponsor you, because this project is in really good shape already.

[aklinker1]

I use an ultra-wide monitor, I'll give UltraWideo a go! 40k users is awesome. I swear I've seen the logo before, maybe while browsing the CWS...

Once it's using WXT, can I add it to the list of extensions using WXT at the bottom of https://wxt.dev/? I need to add my work extension as well.

I'll try to contribute with things that I find interesting and also sponsor you, because this project is in really good shape already.

Wow, thanks for the sponsor! I really appreciate that :) It's very motivating to keep doing OSS when people appreciate my work :)

[dvlden]

As long as it's nothing crazy (screen size wise), I think you'll like UW extension. I used it before on my LG UW 34", but now I am casually using it on my MacBook, cause it helps there too.

I'm happy if you saw the logo before, full rebranding along with the full rewrite is going to be in the process. I decided to redo everything it has now + some more features and then later on implement in-app purchases using Stripe and offers some pro features. So freemium model basically.

Sure thing, you can add it to the list, I'd appreciate that. I'll be happy to put wxt on the "Welcome" screen of the post-install, if you want that.

You are most welcome.