We're looking for a person or people to help audit MDN to find places we could speed up. Is this you or someone you know? Check out the RFP: https://mzl.la/2IHcMiE



この翻訳は不完全です。英語から この記事を翻訳 してください。

addons.mozilla.org (AMO) でのレビュープロセスを完了するには、レビュアーはあなたの拡張機能のコードを読めないといけません。ビルドプロセスで拡張機能のコードが読み辛くなることがあります。そのプロセスにはコードの難読化や最小化(minifying)のほか、モジュールバンドラーや同様なツール(例えば webpack)で、ライブラリーとその他の拡張機能コードの協調させるためのものが含まれます。拡張機能のコード作成にこうしたツールを使っていないかもしれませんが、サードパーティのライブラリーで最小化やその他の読み辛くする処理されたものを使っている場合があります。こうした場合、AMO に拡張機能をアップロードするときには、次のことが必要です:

  • ソースコードと、それをビルドして、拡張機能を読みにくくしている処理の手順を提供します。
  • 拡張機能で最小化されたサードパーティライブラリーを含めている場合、ライブラリーのソースコードのリンクを提供します。
Obfuscating or minifying your code isn't recommended. It rarely protects your code, as these techniques can be reversed using tools such as JSNice and JS Beautifier. And, unlike the advantage that minified code offers web pages loaded over the internet, as extension code is loaded from a local source the performance benefits are not significant.

If you don't provide source code with clear instructions and the reviewer cannot evaluate your extension, it may be rejected.


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.


You must upload your extension’s source code when its code was created using:

Any source code that you submit is only accessible to a small group of admin reviewers.


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 run uglifyjs 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, 例えば、 yuicompressor.
  • a list of all the commands to generate an identical copy of the extension from the source code, 例えば、 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.


If you need to provide it, matching source code must be attached to every extension version.

You can submit your source code in two ways:

  • during the extension upload process, in the step where you upload your extension:

Shows how source code can be attached during the extension upload process

  • 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:

Shows how source code can be attached after the extension has been uploaded

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.

You must provide a link to the source code for any minified third-party libraries included in your extension.

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.

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.


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.


 このページの貢献者: Uemmra3
 最終更新者: Uemmra3,