To complete the review process at addons.mozilla.org (AMO), reviewers must be able to read the code in your extension. Some build processes render extension code difficult to read. These processes include obfuscating or minifying your code, as well as the use of module bundlers or similar tools, such as webpack, to incorporate libraries and other code into your extension. You might not use these processes to create your extension’s code, but you might use third-party libraries that have been minified or otherwise rendered difficult to read. In these cases, when you upload your extension to AMO, you will need to:
- provide your source code and instructions for building that source code, where build processes render your extension’s code hard to read.
- provide links to the library source code, where you include minified third-party libraries in your extension.
If you don't provide source code with clear instructions and the reviewer cannot evaluate your extension, it may be rejected.
Provide your extension source code
Here you can find details of when you must provide your extension’s source code, details of the information you need to provide about the build process, and how to upload your source code.
When must source code be uploaded?
You must upload your extension’s source code when its code was created using:
- code minifiers or obfuscators, such as uglifyJS or Google Closure Compiler.
- tools that generate a single file from other files, such as browserify or webpack.
- template engines, such as handlebars or css2js.
- any other custom tool that takes files, applies pre-processing, and generates file(s) to include in the extension.
Provide build instructions
An important aspect of reviewing source code is confirming that it's the same code as used in your extension. This is to ensure that a malware author doesn't provide legitimate-looking sources, but has added a backdoor to the minified code. It is, therefore, necessary for the reviewer to rebuild your extension from the source code.
To reproduce the build, the reviewer runs the instructions you provided and then uses a diff tool to compare the generated sources to those in the extension. There must be no differences. The easiest way to provide the build instructions is to include a README file with the submitted source code. If it’s one or two files that are processed, for example obfuscated, the instructions can be something like
data/mycoolstuff.js. If the extension is more complex, provide a script to perform the build. When preparing your instructions, remember to include:
- operating system and environment requirements.
- details, including required version and installation instructions, of any tools or utilities that need to be downloaded, for example, yuicompressor.
- a list of all the commands to generate an identical copy of the extension from the source code, for example, npm install or a grunt target. Ideally, you should include every command in the build script file.
The tools you use to obfuscate, minify, or concatenate your source code:
- must be open source: we cannot verify a build made with commercial tools.
- cannot be web-based: all review builds are run locally. Using a web-based tool doesn’t allow the reviewers to be certain that your sources match the minified code. Some web-based tools offer a version that can be run locally, in which case provide a script to run the tool locally.
When using npm, yarn, or other package management tools that support it, be sure to include the lockfile, for example,
package-lock.json. Otherwise, reviewers may use a different version resulting in differences between the generated code and that in the extension.
Assume the reviewer hasn’t installed any developer tools on their computer, that is, make sure you include all the set-up and build instructions to create your code. However, you don’t need to describe how to install common tools such as npm or node.
Tip: Use a build target relative to the directory containing the source, such as a
dist subfolder. This makes it easier for the reviewer to locate your extension’s built code.
How to upload source code
You can submit your source code in two ways:
- during the extension upload process, in the step where you upload your extension:
- if you’ve already uploaded your extension, open Manage Status & Versions, select the version you want to attach source code to, and submit your files in the source code section:
Provide links to source code for third-party libraries
Here you can find details of when you must provide links to the source code of third-party libraries, how to determine the link to provide, and how to communicate the link to reviewers.
When must links to source code be provided?
You must provide a link to the source code for any third-party libraries included in your extension, minified or not.
How to determine the source code link
You must provide links to the original copies of the files included in your extension and links to the readable source code for those files. For repositories or version controlled files, please specify the link using the revision or tag that you’ve used.
You should download third-party libraries from their official site, not from a CDN or other location. This point is important. Reviewers confirm that your code contains the original library using checksums. Unofficial sources often make small changes to a library’s files, such as whitespace changes, so the checksums don't match.
Example: If you’re using the minified version of mousetrap release 1.4.2 (because you haven’t had the chance to update to the latest version) the following links are incorrect.
https://craig.is/killing/mice—using the main website, which only shows the latest version.
https://github.com/ccampbell/mousetrap/blob/master/mousetrap.min.js—using the master branch, which may change anytime.
https://craig.global.ssl.fastly.net/js/mousetrap/mousetrap.min.js?71631— using the link to a CDN, which could differ from the source.
The correct link is
which links to the exact file, using the tag for the version.
Tip: If the library is on GitHub, you can usually find this version under the “releases” link, then click on the small tag icon next to the version number and navigate to the file in the repository.
Communicating source code links to the reviewer
How you communicate the links to the source code for third-party libraries depends on whether you’re also providing your extension’s source code:
- if you’re also providing your extension’s source code, add links to the third-party libraries to the README file included with your source code.
- if you’re only providing links to third-party libraries, add the links to the “Notes to Reviewers” section of your extension’s details on AMO.
Source code checklist
Use this checklist to confirm that you are providing the right details with your source code submission:
- If you use them, are your build tools:
- open source?
- able to be run on the reviewer’s computer?
- Does your source code package include:
- for minified third-party libraries used in your extension: name, version number, and exact link to the source code from its official location?
- source code for any private repositories or frameworks used in your add-on?
- a README file that includes:
- details of the operating system used for the build?
- details of any specific versions of tools or utilities needed?
- links to any tools or utilities that need to be downloaded?
- guidance for installing any downloaded tools and utilities, for example, links to online instructions?
- instructions for building your add-on code or details of any scripts provided?
- your build script?
- the version lockfile for any package management tools, such as npm or yarn?
- anything else needed to complete the build of your extension’s package?
Remember, if you miss any of the necessary content from your uploaded source code package the reviewer will have to get in touch to request the missing items. This could delay the completion of your extension’s review or, in the worst-case, result in your extension being taken down because we can't confirm it complies with the add-on policies.