Let me expand on that a little bit, as I made the suggestion. I’m not saying that you need to avoid all polyfills that browserify adds, I just think it would be good to reduce them as possible.
For example, the Buffer
polyfill is about 40kb large. If you can avoid using Buffer
, this would save a lot of review time. Sometimes you can use native features of the browser. For example atob and btoa are functions native to the browser, using them would be one line. In node, doing base64 encoding requires the Buffer
module. So to reduce lines, you could just use the native version instead. There are a few ways to do this:
-
Find a module that takes care of this.
The btoa-lite module does this for the example I posted above, there may be others around. It does so by using a trick in package.json:
“main”: “btoa-node.js”,
“browser”: “btoa-browser.js”,
browserify will load btoa-browser.js
instead which is only a few lines.
- Use your own polyfill and trick browserify’s static analysis.
If there is no such module, then you can write your own. You can either do it like the btoa module above, or inline using the trick here. The basic pattern is require(false || "module");
which will make browserify not load the polyfill. You’ll have to provide your own alternative though.
If none of this is at all possible for your add-on, then you can still resubmit. Regardless of if you use the polyfills or not, it is very helpful to upload the files you’ve written, before they have been browserified. To do this you should zip up the files, provide instructions on how to turn the source into the complied version (e.g. “run browserify file1.js file2.js”), then use the source upload feature on addons.mozilla.org.
This will allow us to view each file separately, and skip those files provided by third party libraries that have already been reviewed in another project.
Hope this explains the situation.