[Akkuma]

This isn't true if you use uglify at all. I literally had to go into IRC and try and figure out why a hotfix for our extension was taking so long to get through the process (we had been sitting in it for at least 3 days if not a week IIRC). The response I got in IRC was that I would have to literally come and ask for someone's assistance to bump up the review on my company's extension each time we hotfixed, as we got placed in a special queue that required an admin and not just any volunteer in part due to our use of uglify causing the code to be obfuscated.

The worse part is that uglify is required for us to even get the extension signed, due to Firefox's arbitrary individual file size limit.

Prior to Mozilla getting their act together it literally was over a month of waiting for them to review our extension, so we just bailed altogether as their entire process is terrible for pretty much no real gain. I then tried again once the queue had dropped from ~400 to ~150 and the wait time finally became reasonable.

I mean the process was/is so bad, they literally had an issue on github to just automatically approve extensions based on some criteria due to the huge backlog. I cannot get an unlisted extension released with the same version as a listed extension, so we completely bailed on using Mozilla's hosting at all, since all it does is cause a liability until we can push out fixes the same day without manual intervention.

To top this off, every single time we make a new release, we'd have to explain the extension, how to build it, etc. and provide sources to the code. Our extension is also a regular web extension.

[orclev]

I'm curious to know what extension you're creating that's so massive it needs a minifier/obfuscator to be run on it so that it's small enough to fit under the file size limits. Also just to clarify, what is the file size you're being requested to be under? Are we talking kilobytes, or megabytes here, because a megabyte of JS is an awful lot of code in a single file.

Taking a look at mozilla's publishing guidelines they're quite clear that you can publish an addon in obfuscated or minified form, but that you need to provide them an unobfuscated/unminified copy of the of the source code to review as well as instructions on how you performed the obfuscation/minification (presumably to run it themselves and compare the output). All of that seems fairly reasonable since you don't want people distributing malware on AMO. One thing I don't see mentioned anywhere in there is a size limit on files though, so I'm very interested to hear what this apparently undocumented requirement is.

[Akkuma]

The file size limit is 4/4.5MB.

I work at Virtru. The short summary is that we make a client-side encryption extension for the content of your email. There are certainly things we can do to reduce the file size. However, the business value of doing so is limited, particularly in the context of an extension. It is also much more limited when Firefox itself is vastly less popular than Chrome today and we have no issues from Chrome.

We use webpack, so all our dependencies, which may not be optimized for file size for browser usage get pulled in as well.

As I previously stated, so not sure why I'm having to repeat this, that the entire process due to the minification creates a huge barrier for any business that is trying to fix things in a reasonable amount of time. You get thrown into an admin queue, which moves at a snail's pace, EVERY time you upload a new version you have to add instructions again, EVERY time there is a different reviewer with the same question you have to answer them again. Mozilla isn't sitting there actually reviewing your source code in an intelligent way. We were dinged on 2 uses of eval. What is hilarious the uses came from within very well known libraries, jQuery, and Bluebird. If they were really reading the source code, they would have known that we didn't write that, 1 of the uses we never call the function that contained it, and bluebird is using it as a de-optimization strategy to prevent a function optimization that make objects fast.