How about a standard script for source code submissions?

Add-ons addons.mozilla.org
#1

Hello Review Team,

I am hoping this message reaches you. I have ported an existing Chrome extension to Firefox, and now need to submit it to the AMO. I have been running its four javascript sources through Closure Compiler and then through either javascriptobfuscator.com or javascript-obfuscator on GitHub. With four files and a release every couple of months, it has been no problem to do this manually using the online services. The Chrome Store then publishes the obfuscated code after an automatic scan.

Now I see that the AMO Reviewer Team will need to examine the original source, run it through minimizer and obfuscator, and finally check that the output exactly matches the xpi. I am not fussing about this requirement - it seems entirely reasonable.

What I am fussing about is having to spend a day figuring out obtuse package installers and learning enough of a scripting language - bash, make, Perl, Python, ant, gulp, grunt, belch, or whatever - in order to hack out a 10 line script that lets me publish a free Add-on. And on your end, as editors, I imagine that you see dozens of such homebrew scripts every day, all different, that you have to check for honesty, and then figure out how to run on your own systems. Furthermore, if their README instructions happen to be indecipherable, you have to reject their entry, and get back to the developer for yet another round. It seems an enormous waste of time for everyone.

So how about this instead? The Review Team publishes a script template and package installation instructions that handle the most common js post-processors. I imagine this would include Closure Compiler, uglifyjs, minify, javascriptobfuscator, javascript-obfuscator, but you will know exactly which ones are frequently used. This script generates the “Desired Outcome” exactly, as shown on https://developer.mozilla.org/en-US/Add-ons/Source_Code_Submission
The developer only has to minimally edit the script template, place their source files in the appropriate directory, and run it. The reviewer checks and runs the same lightly edited standard script to verify the xpi.

To me, it looks like everyone wins: developers collectively save much time; reviewers need to understand only one standard script (with perhaps small edits), saving time and hassle; and the lower barrier to entry for Add-Ons benefits Firefox users overall.

Thanks for your attention to this suggestion. I await your reply, in the hope neither learning yet another programming language, nor forcing a volunteer reviewer into a dozen tedious manual operations.

Best Regards,
Doug M

#2

Adding the review admins: @TheOne @mozkewisch @noitidart

(Most of us were away at an event last week)

#3

Oops we missed your message. Excuse that, thanks for your patience. For now go ahead and list the steps you manually take. Please keep it very detailed. I’ll reproduce the obfuscation manually, and see if it’s easy to turn that into a script. If it is then I’ll do it and share with you. Please link me to the addon once uploaded.

#4

While we could certainly create a simple Gruntfile with supporting directories, the problem is that each tool has different requirements and each developer also has. If we made one project that would include all common post-processors, the dependency tree would be huge and there would be a lot of code just for some simple tasks.

If all you want to do is create an add-on you can use the web-ext tool, this does not do any minifying. Doing it this way is actually the easiest for us, since you wouldn’t have to submit source code and we wouldn’t have to reproduce the sources.

Nevertheless, I have also thought about providing such a standardized script and possibly automating the reproduction steps. I don’t know when I will get around to this, but in the meanwhile if you want to minify your code I’d suggest the use of grunt + grunt-contrib-uglify, if you want to obfuscate it then grunt + grunt-closure-compiler. I believe both products create reproducible results. If you want to combine files into one then use browserify instead of webpack.

#5

Thanks for taking the time to post responses and suggestions. Good to know you are looking at the issue. Meanwhile, I’ve scripted parts of the process, and would welcome any improvements or suggestions.