jpm

Der Node basierte Ersatz für cfx, erlaubt das Testen, Starten und verpacken eines Add-Ons.

Schauen Sie sich das jpm Tutorial als Einführung an.

jpm wird folgendermaßen verwendet:

jpm [command] [options]

jpm unterstützt die folgenden globalen Optionen:

-h, --help        - Zeigt eine Hilfsnachricht 
-V, --version     - Anzeigen der JPM Versionsnummer

Installation

jpm wird über den Node Package Manager npm installiert. npm ist im Installer von Node.js enthalten, welches Sie unter nodejs.org finden.

Nachdem Sie npm installiert haben, können Sie jpm wie jedes andere npm Paket installieren:

npm install jpm -g

Abhängig von ihren Einstellungen, müssen Sie den Befehl möglicherweise mit Adminrechten installieren:

sudo npm install jpm -g

Tippen Sie folgendes in die Eingabeaufforderung:

jpm

Es sollte sich eine Zusammenfassung der jpm Kommandos öffnen. Im Gegensatz zu cfx ist jpm in jeder Eingabeaufforderung verwendbar, solange Sie es mit der Option -g installiert haben.

Probleme?

Falls Sie die Zusammenfassung nicht erhalten, fragen Sie nach Hilfe. SDK Benutzer und Teammitglieder des Projekts diskutieren  über Probleme und Vorschläge in der  project mailing list. Someone else may have had the same problem you do, so try searching the list. You're welcome to post a question, too. You can also chat with other SDK users in #jetpack on Mozilla's IRC network.

Command reference

There are six jpm commands:

jpm init

This command initializes a new add-on from scratch.

Create a new directory, change into it, and run jpm init.

mkdir my-addon
cd my-addon
jpm init

You'll then be asked to supply some information about your add-on: this will be used to create your add-on's package.json file.

• title
• name: this defaults to the name of the directory in which you are running jpm init. Unless an id field is present in package.json, jpm will prepend "@" to name and use the result as the id field in the add-on's install manifest.
• version
• description
• entry point (which maps to "main" in package.json)
• author
• engines (supported applications)
• license

Most of these fields have a default, which is shown in brackets after the question. If you just press Enter, your add-on will get the default value.

Once you've supplied a value or accepted the default for these properties, you'll be shown the complete contents of "package.json" and asked to accept it.

Then jpm will create an skeleton add-on, as a starting point for your own add-on development, with the following file structure:

• my-addon
  • index.js
  • package.json
  • test
    • test-index.js

jpm run

This command runs a new instance of Firefox with the add-on installed:

jpm run

jpm run accepts the following options:

jpm run -b /path/to/Firefox/Nightly

jpm run --binary-args -jsconsole

jpm run --binary-args '-url mzl.la -jsconsole'

jpm test

Use this command to run an add-on's unit tests. It will:

• look for a directory called "test" under the add-on's root
• open every file in there whose name starts with "test-" (note the hyphen after "test" in the filename. jpm test will include a file called "test-myCode.js", but will exclude files called "test_myCode.js" or "testMyCode.js")
• call every function exported from that file whose name starts with "test"

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:

jpm test -b /path/to/Firefox/Nightly

jpm test --binary-args -jsconsole

jpm test --binary-args '-url mzl.la -jsconsole'

jpm test --filter base64:btoa

jpm test --stop-on-error

jpm test --times 2

jpm xpi

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 and creates the corresponding XPI file. It ignores any ZIPs or XPIs in the add-on's root, and any test files.

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:

jpm xpi -v

jpm post

This command packages the add-on as an XPI file, the posts it to some url.

jpm post

It looks for a file called package.json in the current directory and creates a XPI file with which to post to the --post-url.

jpm post accepts the following options:

jpm post --post-url https://localhost:8888/

jpm post --post-url https://localhost:8888/ -v

jpm watchpost

This command packages the add-on as an XPI file, the posts it to some url whenever a file in the current working directory changes.

jpm watchpost

Creates a XPI whenever a file in the current working directory changes and posts that to the --post-url.

jpm watchpost accepts the following options:

jpm watchpost --post-url https://localhost:8888/

jpm watchpost --post-url https://localhost:8888/ -v

Techniques

Selecting a browser version

By default, jpm run and jpm test will run 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", "aurora", "beta", or "firefox" and jpm will look in the default location for these Firefox versions:

  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 will first check  JPM_FIREFOX_BINARY, and use this as the path if it is set.

Using .jpmignore to ignore files

Using .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.

Using profiles

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 will not, by default, be 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

If you supply --profile but its argument is not the name of or path to an existing profile, jpm will open the profile manager,  enabling you to select and existing profile or create a new one:

jpm run --profile i-dont-exist

Developing without browser restarts

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:

• make a change to your add-on
• run jpm post --post-url https://localhost:8888/, to make a xpi and post it.

You could even automate this workflow with a simple script. For example:

jpm watchpost --post-url https://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 output from console.log() messages, you'll have to tweak a setting. See the documentation on logging levels for the details on this.

Overloading the built-in modules

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 will use 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:

• get a local copy of the SDK modules that you want: this usually means checking out the SDK from its GitHub repo
• set the JETPACK_ROOT environment variable to your local copy
• pass the -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 don't 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/SDK/"