Add-ons using the techniques described in this document are considered a legacy technology in Firefox. Don't use these techniques to develop new add-ons. Use WebExtensions instead. If you maintain an add-on which uses the techniques described here, consider migrating it to use WebExtensions.
From Firefox 53 onwards, no new legacy add-ons will be accepted on addons.mozilla.org (AMO).
From Firefox 57 onwards, WebExtensions will be the only supported extension type, and Firefox will not load other types.
Even before Firefox 57, changes coming up in the Firefox platform will break many legacy extensions. These changes include multiprocess Firefox (e10s), sandboxing, and multiple content processes. Legacy extensions that are affected by these changes should migrate to WebExtensions if they can. See the "Compatibility Milestones" document for more.
A wiki page containing resources, migration paths, office hours, and more, is available to help developers transition to the new technologies.
Use .jpmignore
to ignore files from your XPI builds created via jpm.
Using .jpmignore
to ignore files and directories
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 and directories 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 # Ignore specific directory # You can start patterns with a forward slash (/) to avoid recursivity. # You can end patterns with a forward slash (/) to specify a directory. /sample/
A .jpmignore
file with the above contents would ignore all zip files and .DS_Store
files and sample directory from the xpi generated by jpm xpi
.
Using .jpmignore
to allow files
Everything in your add-on directory will be included in the xpi file you make with jpm xpi
. If your project folder contains a lot of files that aren't necessary for the xpi to run, like documentation, jshint
, etc., you can use .jpmignore
as a whitelist instead of a blacklist. For example:
.* * !/data/** !/lib/** !/locale/** !/node_modules/** !/package.json !/icon.png !/icon64.png !/COPYING !/bootstrap.js !/install.rdf
This would include all editor backup files and similar in the whitelisted subdirectories, to avoid that you can append another blacklist after the whitelist. This one would work for Xemacs:
.* * !/data/** !/lib/** !/locale/** !/node_modules/** !/package.json !/icon.png !/icon64.png !/COPYING !/bootstrap.js !/install.rdf *~ \#*