Misc. JPM dirty laundry

Notes on problems encountered moving from CFX to JPM:

  1. “JPM undefined”. Known bug, in Bugzilla.
  2. The main JPM document should prominently mention the CFX to JPM conversion guide at: “https://developer.mozilla.org/en-US/Add-ons/SDK/Tools/cfx_to_jpm”. The main JPM page oversimplifies some issues.
  3. The new “bootstrap.js” used by JPM contains code that AMO’s validator complains about. Known bug.
  4. The output file from “jpm xpi” is based on the “id” and version, or the “name”. When both “id” and “name” are present in the “package.json” file, “id” is used, so you get a long ID-based filename. Documentation is ambiguous. Known bug, in Bugzilla.
  5. If the “package.json” file contains an old-style 2-part version number, the output version is silently 0.
  6. Contrary to documentation, “jpm xpi” will put .xpi files inside .xpi files, as long as they have a different name than the .xpi file being generated. If you change the version, which changes the .xpi filename, this can easily happen. The add-on still works but is bloated, and reviewers reject for this. Just filed a bug.

None of these are killer problems, just things that waste a day of time for each add-on developer.

1 Like

As for #5, https://developer.mozilla.org/en-US/Add-ons/SDK/Tools/package_json under version says it must be a semver for JPM.