We use Webpack to bundle our extension. Firefox's approval process requires that each file be less than 4mb, so you might need to split up your bundles or make sure you're not including code you don't need (via tree-shaking).
If you're manually splitting up bundles, you'd just include multiple script tags on the page.
Firefox doesn't support Webpack's method for automatic bundle splitting and dynamic imports out of the box. We use a package webpack-target-webextension to for that (full disclosure: we haven't tried to get our extension approved by the Firefox webstore yet, though).
webpack-bundle-analyzer is also helpful for understanding what's driving the size of the bundle
Thanks! There's some changes I'll likely be making with respect to passing messages between parts of the extension (we need more control over tab/frame than I originally anticipated, need to write testing mocks for it), but overall the ergonomics are pretty good
Hey @viperfx! While some extensions load code remotely (<script src="http://example.com/some_code.js">), most I've seen include the code in the extension itself with remote calls to external services with fetch/AJAX where necessary. I'd guess that if you load remote code then your extension will likely take longer to pass review in the various extension stores.
Furthermore, Chrome (and maybe the other browser vendors?) are disallowing remote code in manifest v3 to improve security. So if you want your extension to work long-term, you're better off baking the code locally.
That's what I thought too! I am building my app with React/TypeScript and I have been building it locally.
When deploying with source code, is it allowed to minify the code?
Also if I build a chrome app, which stores can it be published with? For example, can it work with firefox or edge too? is there many changes needed for it to work?
You are totally allowed to minify code, though some markets may ask you for more info before approving your extension. It's never happened to me but I heard (from @timleland?) that sometimes Mozilla can ask you for the unminified source + build scripts before they let you launch on the Firefox add-ons market.
You'll have to test out if your extension works in the various browsers. Often your extension will just work but sometimes you'll need to change things. The biggest one is that some browsers use the browser object and some use the chrome object with differences in callback/Promise implementation. I'm sure you can find things about that on Google if you need more details.
Yes, I have to submit the source code and build steps for Firefox. This may be because my Weather Extension is part of their "Recommended" program and they are stricter on the extensions.
Since all of my extensions started for Chrome, I just replace chrome with browser and it works.
We've been using Mozilla's web extension polyfill https://github.com/mozilla/webextension-polyfill (actually, webextension-polyfill-ts which is a Typescript wrapper), because working with Promises is a lot nicer than callbacks.
IIRC, Firefox's submission process does indeed let you the submit unminified source privately for review. In general, there's not much benefit to minifying extension code because its not being transmitted over the network multiple times. However, with Firefox, a gotcha is that each script in your extension you submit for approval has to be less than 4mb for historic reasons.
We use Webpack to bundle our extension. Firefox's approval process requires that each file be less than 4mb, so you might need to split up your bundles or make sure you're not including code you don't need (via tree-shaking).
If you're manually splitting up bundles, you'd just include multiple script tags on the page.
Firefox doesn't support Webpack's method for automatic bundle splitting and dynamic imports out of the box. We use a package webpack-target-webextension to for that (full disclosure: we haven't tried to get our extension approved by the Firefox webstore yet, though).
webpack-bundle-analyzer is also helpful for understanding what's driving the size of the bundle
You can see our configurations here: https://github.com/pixiebrix/pixiebrix-extension/tree/main/browsers. Our extension is open-source. When we submit our extension for review, we give them a link to the GitHub actions build.
Thanks for the helpful advice. Your repo is great learning resource for building extensions.
Thanks! There's some changes I'll likely be making with respect to passing messages between parts of the extension (we need more control over tab/frame than I originally anticipated, need to write testing mocks for it), but overall the ergonomics are pretty good
Hey @viperfx! While some extensions load code remotely (
<script src="http://example.com/some_code.js">
), most I've seen include the code in the extension itself with remote calls to external services withfetch
/AJAX where necessary. I'd guess that if you load remote code then your extension will likely take longer to pass review in the various extension stores.Furthermore, Chrome (and maybe the other browser vendors?) are disallowing remote code in manifest v3 to improve security. So if you want your extension to work long-term, you're better off baking the code locally.
That's what I thought too! I am building my app with React/TypeScript and I have been building it locally.
When deploying with source code, is it allowed to minify the code?
Also if I build a chrome app, which stores can it be published with? For example, can it work with firefox or edge too? is there many changes needed for it to work?
You are totally allowed to minify code, though some markets may ask you for more info before approving your extension. It's never happened to me but I heard (from @timleland?) that sometimes Mozilla can ask you for the unminified source + build scripts before they let you launch on the Firefox add-ons market.
You'll have to test out if your extension works in the various browsers. Often your extension will just work but sometimes you'll need to change things. The biggest one is that some browsers use the
browser
object and some use thechrome
object with differences in callback/Promise implementation. I'm sure you can find things about that on Google if you need more details.Yes, I have to submit the source code and build steps for Firefox. This may be because my Weather Extension is part of their "Recommended" program and they are stricter on the extensions.
Since all of my extensions started for Chrome, I just replace chrome with browser and it works.
Firefox supports the chrome.* APIs in order to make porting easier. More information is available here: https://extensionworkshop.com/documentation/develop/porting-a-google-chrome-extension/
We've been using Mozilla's web extension polyfill https://github.com/mozilla/webextension-polyfill (actually, webextension-polyfill-ts which is a Typescript wrapper), because working with Promises is a lot nicer than callbacks.
IIRC, Firefox's submission process does indeed let you the submit unminified source privately for review. In general, there's not much benefit to minifying extension code because its not being transmitted over the network multiple times. However, with Firefox, a gotcha is that each script in your extension you submit for approval has to be less than 4mb for historic reasons.
Thanks, I didn't know that existed. I will check it out.