{{LegacyAddonsNotice}}{{AddonSidebar}}
jpm は Add-on をテスト、実行及びパッケージ化することができるコマンドラインツールです。
これはjpmのリファレンスページです。開始のためのjpmチュートリアルも参照してください。
jpmの使用方法は次のとおりです。
jpm [command] [options]
jpmは次のグローバルオプションをサポートしています：
-h, --help - show a help message and exit
-V, --version - print the jpm version number
--addon-dir - directory for your source code,
defaulting to the current directory
jpmは、nodeパッケージマネージャnpmとともに配布されます。
npmをインストールするには2つの方法があります。
sudo apt-get install nodejs nodejs-legacy npmと入力します。インストールできたかをテストするには、次のコマンドを実行します。
/usr/bin/env node -v
"/usr/bin/env: node: No such file or directory"というエラーメッセージが表示され、パッケージマネージャーを使用してnodejsをインストールした場合、nodejsは別の実行可能ファイル名でインストールされている可能性があります。ただし、jpmとの互換性を確保するには、PATHにnodeという名前で存在する必要があります。DebianとUbuntuでは、これは互換性パッケージnodejs-legacyを確実にインストールすることで解決できます。
sudo apt-get install nodejs-legacy
他のディストリビューションでは、nodejsへのローカルシンボリックリンクを手動で作成する必要があります。
sudo ln -s "$(which nodejs)" /usr/local/bin/node
npmがインストールされ、PATHにnodeが追加されたら、他のnpmパッケージと同じようにjpmをインストールします。
npm install jpm --global
設定に応じて、次のコマンドをを管理者として実行する必要があります： sudo npm install jpm --global
jpmをグローバルにインストールしたくない場合、またはインストールできない場合は、代わりにローカルにインストールすることができます。
cd $HOME && npm install jpm
ローカルにインストールしたときにターミナルからjpmを実行するには、最初に"$HOME/node_modules/.bin/"というディレクトリをターミナルのPATHに追加する必要があります。$HOME/.profileファイルの最後に次の行を追加してPATHに永続的に（新しい端末が開くたびに.profileファイルが実行されます）追加します。
export PATH="$HOME/node_modules/.bin/:$PATH"
あるいはgitを使って最新のjpmを入手することもできます。
git clone https://github.com/mozilla-jetpack/jpm.git cd jpm npm install npm link
インストール後、コマンドプロンプトで次のように入力します。
jpm
利用可能なjpmコマンドを要約した画面が表示されます。cfxとは異なり、jpmは --globalフラグを付けてインストールすることで、起動するすべてのコマンドプロンプトで使用できます。
Firefox 48では、ブランド版のリリースまたはベータ版のFirefoxでは、署名されていないアドオン（つまり、開発中のアドオン）を使用することはできません。したがって、別のバージョンのFirefoxをダウンロードしてインストールする必要があります。旧バージョンのFirefoxを必要としない場合、あなたのオプションはFirefox Developer Edition、Firefox Nightly、Unbranded Beta、またはUnbranded Releaseです。
あなたのアドオンをテストするときは、jpm runコマンドに-bオプションを使う必要があります。ブラウザのバージョンの選択を参照してください。
これが表示されない場合は、ヘルプを求めてください。SDKユーザーとプロジェクトチームメンバーはプロジェクトのメーリングリスト上で問題と提案について話し合っています。他の人が同じ問題を抱えている可能性がありますので、リストを検索してみてください。質問を投稿することもできます。MozillaのIRCネットワーク上の#jetpackで他のSDKユーザーとチャットすることもできます。
jpmは次のコマンドをサポートしています。
jpm init |
あなたのアドオンの出発点としてスケルトンアドオンを作成します。 |
jpm run |
アドオンがインストールされているFirefoxのインスタンスを起動します。 |
jpm test |
アドオンの単体テストを実行します。 |
jpm xpi |
Firefoxのアドオンのインストールファイル形式であるXPIファイルとしてアドオンをパッケージ化します。 |
jpm post |
アドオンをXPIファイルとしてパッケージ化し、それをいくつかのURLに投稿します。 |
jpm watchpost |
ファイルが変更されたときにアドオンをXPIファイルとしてパッケージ化し、それをいくつかのURLに投稿します。 |
jpm sign |
アドオンをXPIファイルとしてパッケージ化し、Mozillaが署名した新しいXPIを取得します。 |
このコマンドは、新しいアドオンを初期化します。
ディレクトリを作成してそこに移動し、jpm initコマンドを実行します。
mkdir my-addon cd my-addon jpm init
ここでアドオンに関するいくつかの情報を入力するよう求められます。これは、アドオンのpackage.jsonファイルの作成に使用されます。
idフィールドがpackage.jsonに存在しない限り、jpmはnameに "@"を付加し、その結果をアドオンのインストールマニフェストのidフィールドとして使用します。これらのフィールドのほとんどはデフォルト値があり、質問の後に角括弧で表示されています。Enterキーを押すだけでアドオンがデフォルト値になります。
値を提供したり、これらのプロパティのデフォルトを受け入れると、 "package.json"の完全な内容が表示され、それを受け入れるように求められます。
次にjpmは、以下のファイル構造で、アドオン開発の出発点としてスケルトンアドオンを作成します。
このコマンドは、アドオンがインストールされたFirefoxの新しいインスタンスを実行します。
jpm run
jpm run は次のオプションを受け入れます：
-b --binary BINARY |
BINARYで指定されたバージョンのFirefoxを使用してください。 BINARYは、フルパスまたはカレントディレクトリに対する相対パスとして指定できます。 jpm run -b /path/to/Firefox/Nightlyブラウザのバージョンの選択を参照してください。 |
--binary-args CMDARGS |
Firefoxに追加の引数を渡します。 たとえば、Firefoxに jpm run --binary-args -jsconsole 複数の引数、または空白を含む引数を渡すには、それらを引用符で囲みます。 jpm run --binary-args '-url mzl.la -jsconsole' |
--debug |
アドオンに接続されているアドオンデバッガを実行します。 |
-o --overload PATH |
Firefoxに組み込まれたSDKモジュールを使用するのではなく、PATHにあるモジュールを使用します。 詳細については、組み込みモジュールのオーバーロードを参照してください。 |
-p --profile= |
デフォルトでは、jpmは、jpm runを呼び出すたびにきれいな一時的なFirefoxプロファイルを使用します。既存のプロファイルでFirefoxを起動するようにjpmに指示するには、 PROFILEの値は、プロファイル名またはプロファイルへのパスです。 詳細については、プロファイルの使用を参照してください。 |
-v --verbose |
詳細な操作。 |
--no-copy |
jpm run|testは多くの設定を変更するので、注意して使用してください。メインのプロファイルでは使用しないでください。これは
使用されているプロファイルのコピーを無効にします。これにより、プロファイルを再利用することができます。--profileが使用されている場合のみ適用されます。 |
Use this command to run an add-on's unit tests. The command:
--addon-dir).jpm test include a file called "test-myCode.js", but will exclude files called "test_myCode.js" or "testMyCode.js")jpm test
See the tutorial on unit testing and the reference documentation for the assert module for more details on this.
jpm test accepts the following options:
-b --binary BINARY |
Use the version of Firefox specified in BINARY. BINARY may be specified as a full path or as a path relative to the current directory. jpm test -b /path/to/Firefox/Nightly |
--binary-args CMDARGS |
Pass extra arguments to Firefox. For example, to pass the jpm test --binary-args -jsconsole To pass multiple arguments, or arguments containing spaces, quote them: jpm test --binary-args '-url mzl.la -jsconsole' |
--debug |
Run the Add-on Debugger attached to the add-on. |
-f --filter FILE[:TEST] |
Only run tests whose filenames match FILE and optionally match TEST, both regexps. jpm test --filter base64:btoa The above command only runs tests in files whose names contain "base64", and in those files only runs tests whose names contain "btoa". |
-o --overload PATH |
Rather than use the SDK modules built into Firefox, use the modules found at PATH. If See Overloading the built-in modules for more information. |
-p --profile |
By default, jpm uses a clean temporary Firefox profile each time you call jpm run. Use the The PROFILE value may be a profile name or the path to the profile. See Using profiles for more information. |
--stop-on-error |
By default, jpm test keeps running tests even after tests fail. Specify jpm test --stop-on-error |
--tbpl |
Print test output in Treeherder format |
--times NUMBER |
Run tests NUMBER of times: jpm test --times 2 |
-v --verbose |
Verbose operation. |
--no-copy |
jpm run|testは多くの設定を変更するので、注意して使用してください。メインのプロファイルでは使用しないでください。This only applies when
Disables the copying of the profile used, which allows one to reuse a profile.--profile is used. |
This command packages the add-on as an XPI file, which is the install file format for Mozilla add-ons.
jpm xpi
It looks for a file called package.json in the current directory (or --addon-dir) and creates the corresponding XPI file. It ignores any ZIPs or XPIs in the add-on's root, and any test files. It includes all other files. If you want to exclude extra files, see the .jpmignore file.
Once you have built an XPI file, you can distribute your add-on by submitting it to addons.mozilla.org.
jpm xpi accepts the following option:
--dest-dir |
Optional destination directory for the generated XPI file. The current working directory is the default destination. |
-v --verbose |
Verbose operation: jpm xpi -v |
This command packages the add-on as an XPI file then posts it to some URL.
jpm post
It looks for a file called package.json in the current directory (or --addon-dir) and creates an XPI file with which to post to the --post-url.
jpm post accepts the following options:
--post-url URL |
The URL to post the extension to after creating an XPI. jpm post --post-url http://localhost:8888/ See Using Post and Watchpost for more information. |
-v --verbose |
Verbose operation: jpm post --post-url http://localhost:8888/ -v |
This command packages the add-on as an XPI file then posts it to some URL whenever a file in the current working directory changes.
jpm watchpost
Creates an XPI whenever a file changes in the current working directory (or --addon-dir) and posts that to the --post-url.
jpm watchpost accepts the following options:
--post-url URL |
The URL to post the extension to after creating an XPI. jpm watchpost --post-url http://localhost:8888/ See Using Post and Watchpost for more information. |
-v --verbose |
Verbose operation: jpm watchpost --post-url http://localhost:8888/ -v |
This feature is only supported from jpm 1.0.4 onwards.
This command retrieves a new XPI for your add-on signed by Mozilla. This allows you to self-host your add-on so that users can install it without error when signed add-ons are required.
You can sign an XPI you've already generated by passing the XPI file in the --xpi argument, like this:
jpm sign --api-key ${JWT_ISSUER} --api-secret ${JWT_SECRET} --xpi <xpi file>
Alternatively, you can omit the --xpi argument, in which case jpm sign will generate an XPI from the current directory (or --addon-dir).
jpm sign --api-key ${JWT_ISSUER} --api-secret ${JWT_SECRET}
This submits an XPI it to the addons.mozilla.org signing API, then downloads a signed XPI to the working directory if it passes validation.
To get values for --api-key and --api-secret, you will need to create API credentials on addons.mozilla.org. On the AMO key management page, these values are labeled "JWT_Issuer" and "JWT_Secret".
Here are some possible outcomes of running the sign command:
Under the hood, jpm sign creates an unlisted add-on inside addons.mozilla.org, which means you must distribute the XPI file yourself for your users to install it. If you need to create a listed add-on, just submit it directly to addons.mozilla.org where it is signed automatically. See the debugging section if you are experiencing difficulty installing a signed add-on.
jpm sign accepts the following options:
--api-key=JWT_ISSUER |
API access key (string) generated on the addons.mozilla.org key management page. On the AMO key management page, this value is labeled "JWT Issuer". |
--api-secret=JWT_SECRET |
API access secret (string) generated on the addons.mozilla.org key management page. This value should be guarded with care and never checked into version control. If your secret is compromised, another developer could upload add-ons to your account. You should revoke and regenerate compromised API credentials immediately. On the AMO key management page, this value is labeled "JWT Secret". |
--api-url-prefix=http://.../api |
An optional API URL prefix in case you'd like to use a pre-production signing API. For example, you could pass |
--xpi=/path/to/file.xpi |
An XPI file to sign. When no file is specified, a new XPI will be generated from the current directory (or |
By default, jpm run and jpm test runs the release version of Firefox. You can instruct jpm to use a different version in one of two ways:
You can use the -b or --binary option to instruct jpm to run a different version of Firefox. You can supply a path to a specific binary:
jpm run -b /path/to/Firefox/Nightly
As a shorthand for this, you can pass "nightly", "firefoxdeveloperedition", "aurora", "beta", or "firefox" and jpm will look in the default location for these Firefox versions [Note: As of Firefox 48, the shorthands "firefox" and "beta" will resolve to versions of Firefox which will not run your add-on. This is due to Firefox 48, and later, not having the option to run add-ons which are unsigned.]:
jpm run -b nightly
You can set the JPM_FIREFOX_BINARY environment variable with the path to the version of Firefox you want to run. When you invoke jpm run or jpm test without the -b option, jpm first checks JPM_FIREFOX_BINARY, and use this as the path if it is set.
.jpmignore to ignore filesUsing .jpmignore is similar to using .gitignore with git, .hgignore with Mercurial, or .npmignore with npm. By using this file, you can let jpm know which files you would like it to ignore when building a .xpi file with jpm xpi.
Here is an example:
# Ignore .DS_Store files created by mac .DS_Store # Ignore any zip or xpi files *.zip *.xpi
A .jpmignore file with the above contents would ignore all zip files and .DS_Store files from the xpi generated by jpm xpi.
By default, jpm run uses a new profile each time it is executed. This means that any profile-specific data entered from one run of jpm is not, by default, available in the next run.
This includes, for example, any extra add-ons you installed, or your history, or any data stored using the simple-storage API.
To make jpm use a specific profile, pass the --profile option, specifying the name of the profile you wish to use, or the path to the profile.
jpm run --profile boogaloo
jpm run --profile path/to/boogaloo
Use the profile manager to create a new profile if needed.
If you need changes to the profile to persist, add the --no-copy argument. However beware that jpm might also apply changes to the profile, setting some preferences that will make it unusable for daily usage.
Because jpm run restarts the browser each time you invoke it, it can be a little cumbersome if you are making very frequent changes to an add-on. An alternative development model is to use the Extension Auto-Installer add-on: this listens for new XPI files on a specified port and installs them automatically. That way you can test new changes without needing to restart the browser:
jpm post --post-url http://localhost:8888/, to make an XPI and post it.You could even automate this workflow with a simple script. For example:
jpm watchpost --post-url http://localhost:8888/
Note that the logging level defined for the console is different when you use this method, compared to the logging level used when an add-on is run using jpm run. This means that if you want to see the output from console.log() messages, you have to tweak a setting. See the documentation on logging levels for the details on this.
The SDK modules you use to implement your add-on are built into Firefox. When you run or package an add-on using jpm run or jpm xpi, the add-on uses the versions of the modules in the version of Firefox that hosts it.
As an add-on developer, this is usually what you want. But if you're developing the SDK modules themselves, of course, it isn't. In this case you need to:
JETPACK_ROOT environment variable to your local copy-o option to jpm run or jpm xpi:jpm run -o
This instructs jpm to use the local copies of the SDK modules, not the ones in Firefox. If you do not want to set the JETPACK_ROOT environment variable, you can pass the location of your copy of the SDK modules along with -o:
jpm run -o "/path/to/addon-sdk/"
The path must be an absolute path and point to the SDK's root (not addon-sdk/sdk or addon-sdk/sdk/lib, for instance).
This feature is only supported from jpm 1.0.3 onwards.
When you make updates to your add-on to add features or fix bugs, you'll want any previously installed versions of the add-on to update themselves to the new version.
If you list your add-on on addons.mozilla.org, then all you have to do here is submit the new version; add-ons default to checking addons.mozilla.org for new versions of themselves. You can stop reading this section.
If you do not list your add-on on addons.mozilla.org, you need to generate a Mozilla-signed XPI and tell Firefox where it can find new versions of your add-on. The way this works is:
To do this, include two extra keys in package.json:
updateURL: This URL is included in the install manifest of the XPI file that jpm xpi builds. It points to your update manifest. The updateURL value may be HTTPS. If it is not, then you'll also need to sign the update manifest, and then include the public key using the updateKey field in package.json. See Securing updates for more on this.updateLink: This URL is included in the update manifest file. It points to the XPI, and must be an HTTPS URL.
If you include updateURL and updateLink (and also updateKey in case updateURL is not HTTPS), then jpm xpi will:
updateURL in the XPI it generates.updateLink in the manifest.You then host the update manifest at updateURL, and host new versions of the XPI at updateLink.
For some more details on this, see Automatic Add-on Update Checking.