De cfx à jpm

Un guide pour travailler avec jpm si vous êtes déjà familier avec cfx.

Installation

cfx est basée sur Python et est distribué comme un fichier zip. jpm est baser sur Node.js qui est distribué par npm . Donc, pour jpm vous n'avez pas besoin de Python, mais vous avez besoin npm.

Pour obtenir les mises de cfx vous deviez télécharger et extraire un fichier zip, tandis que pour obtenir la nouvelle version de jpm, utilisez npm update .

Pour obtenir des instructions d'installation de jmp, consultez la section de l' Installation dans la référentiel de jmp.

Activation

Vous devez appeler cfx activate avant de pouvoir utiliser cfx, et cela ne fonctionne que dans le shell de commande de courant:. Si vous ouvrez un nouveau shell, vous devez appeler activate de nouveau

Avec jpm, pas d'activation. Une fois qu'il est installé, vous pouvez simplement l'utiliser.

Incompatibilités

Dans la plupart cas, les add-ons créés avec cfx fonctionnent bien avec jpm. Cependant, il y a quelques différences que vous devez connaitre.

Add-on ID

L'ID de add-on est l'identifiant unique de votre add-on. Dans un xpi, c'est le champ ID dans le fichier Manifest d'instalation de l'add-on (install.rdf).

L'identifiant est utilisé à des fins variées. Par exemple: addons.mozilla.org l'utilise pour distinguer entre les nouvelles add-ons et les mises à jour d'add-ons existantes, et le module simple-storage l'utilise pour déterminer lesquelles des données stockées appartiennent à tel add-on.

Manipulation avec l'ID cfx

Lorsque vous utilisez cfx, l'ID est tiré du champ id dans le fichier de package.json de l'add-on. Vous pouvez éditer ce fichier pour créer votre propre identité, mais si vous ne le faites pas, cfx va le générer pour vous, ce qui va ressembler à quelque chose comme "jid1-F3BoogbjQJE67A". L'ID Add-on doit être l'un des deux types suivant : un GUID ou une chaîne qui comprend un symbole "@". Le SDK ne prévoit que le dernier format, et si l'ID dans package.json ne contient pas de "@", cfx xpi ajouter "@jetpack" dans le champ de package.json, ce qui transforme l'ID de l'add-on.

Donc: si vous n'avez jamais manipulé l'ID lors de l'utilisation cfx, alors la valeur dans le package.json de votre add-on sera quelque chose comme "jid1-F3BoogbjQJE67A", et l'ID correspondant dans la install.rdf sera "jid1-F3BoogbjQJE67A@jetpack".

Manipulation d'ID avec jpm

Lorsque vous créez un xpi avec jpm xpi:

• si le package.json ne comprend pas un champ id, alor l'ID dans l'install.rdf à la valeur de la champ name Préfixé par "@".
• si le package.json inclut un champ id, et il contient «@», alors l'écriture est la même dans install.rdf.
• si le package.json inclut un champ id, sans "@", jpm XPI soulève une erreur et le xpi ne sera pas construit.

Ce que vous devez faire

Tout cela signifie que: si votre package.json contient un champ id, et sa valeur ne contient pas «@», alors vous devez ajouter "@jetpack» lors du passage à jpm .

Si vous faites cela, l'ID de l'add-on sera la même que l'id utilisée avec cfx.

Point d'entrée

Le point d'entrée de l'add-on est le fichier qui est exécutée lorsque l'add-on a besoin de s'initialiser: par exemple, au démarrage de Firefox, ou lorsque l'add-on est installé, activé, ou mis à niveau. Avec cfx, la valeur par défaut à "lib/main.js", même si elle peut être réglée sur un autre fichier en utilisant le main champ dans le package.json .

Dans jpm, le point d'entrée par défaut est "index.js". Donc, lors de la commutation vers jpm:

• renommez vos "main.js" en "index.js" et déplacez les de "lib" vers le plus haut niveau
• ou ajouter un champ main dans package.json avec pour valeur "lib/main.js".

Chargement des modules

L'outil jpm utilise la même logique que Node.js pour déterminer comment résoudre l'argument require(). Dans la plupart des cas, c'est la même logique que cfx. Cependant, il existe quelques différences, parce certaines compatibilités ont été retirées.

Requérir à des modules locaux

Supposons que votre add-on est structuré en modules séparés :

• my-addon
  • lib
    • main.js
    • utils.js

Lorsque vous voulez utiliser un module "utils.js" dans "main.js", vous devez utiliser un chemin relatif à "main.js", et le préfixer avec "./" pour indiquer que c'est un chemin relatif:

var utils = require("./utils");

Cependant, avec cfx vous êtes également autorisé à omettre le "./":

var utils = require("utils"); // this will not work with jpm!

Cette seconde forme ne fonctionnera pas avec jpm.

Requérir des modules de code de test

Similarly, suppose you've written some tests for your add-on:

• my-addon
  • lib
    • my-addon.js
  • test
    • test-my-addon-js

Avec cfx, le code de "test-my-addon.js" peut importer "my-addon.js" en utilisant une déclaration de ce genre:

var my_addon = require("my-addon"); // ceci ne fonctionne pas avec jpm!

Avec jpm, vous devez spécifier le chemin vers «my-addon" explicitement, en utilisant un chemin relatif:

var my_addon = require("../lib/my-addon");

Modules tiers

Le SDK a toujours soutenu les modules tiers: les développeurs peuvent écrire leurs propres modules qui étendent les API du SDK ou ajouter de nouvelles API, et d'autres add-on peuvent faire usage de ces modules de la même manière qu'ils utilisent les modules intégré au SDK.

Dans jpm cette façon d'utiliser des modules tiers ne fonctionne plus. Au lieu de cela, jpm n'accepte que les modules tiers hébergés sur la npm, vous pouvez les utiliser en les installant à partir de la npm dans l'arbre de répertoire de votre add-on. Voir le tutoriel utilisant des modules tiers avec jpm.

Les commandes et les options de commande

Commandes définitivement retiré

jpm ne soutient plus les commandes cfx "interne".

Options définitivement retiré

jpm ne soutient plus :

--extra-packages
--use-config
--package-path
--pkgdir
--no-strip-xpi
--harness-option
--manifest-overload
--output-file
--templatedir
--keydir
--profiledir
--overload-modules
--static-args
--app
--no-run
--addons
--e10s
--logfile
--dependencies
--test-runner-pkg

Au lieu de --profiledir et de --overload-modules, utilisez --profile et --overload

Champs Package.json

Beaucoup de champs package.json sont des commandes implicites de cfx. Dans jpm, nous avons supprimé le soutien de certains de ces domaines, et travaillons toujours sur le soutien des autres.

Champs définitivement retiré

• data
• fullName - use title instead
• lib
• packages
• tests
• icon64

Echappement dans Package.json

Où avec cfx vous auriez dû échapper avec 2 voir 3 barres obliques inverses (\), jpm n'en a besoin que d'une.