Jetpack In The Future

By Erik Vold

The future for Jetpack is coming, this is what it will look like (as far as I see it).

Native Jetpack

The old days of having to use a command line tool or some add-on builder tool to “build” your jetpacks in to add-ons will be no more, very soon. This is a plan which I have been working on which I call Native Jetpack, you can read far more detailed JEP over here.

Native Jetpack (aka bug 915376), simply put, is a plan to make Jetpacks a native extension type, just like old school extensions, and bootstrap extensions are today. If you were not aware, currently Jetpacks must go through a build process which converts them in to bootstrap extensions, which will no longer be necessary in my Native Jetpack plan. So all that will be required in the future is that the Jetpack be zipped and renamed to use a .xpi file extension (rather than a .zip extension).

The way I came to the conclusion that this was necessary was by dog fooding Jetpacks for many years now, and comparing that experience to my experience making vanilla bootstrap extensions. I realized that I would often change a line or two of code and want to manually test that, which is an easy process with bootstrap extensions and a horrible experience with Jetpacks. With the former I merely had to disable, then enable the extension to see my changes, whereas with the Jetpack extensions I either had to use cfx run which required browser restarts, or I had to use cfx xpi and re-install the extension, which was far less productive than even the cfx run option.

There are other third party options that I have heard of, but they seemed to laborious for even me to bother to figure out, and I feel strongly that the Jetpack project must have a solution for this. There was an existing plan before I joined the team to rewrite the build process in JavaScript (from Python which it is currently written in), and ship this JS implementation with Firefox and have Firefox build the Jetpacks instead of an add-on builder and there was a lot of work done in that direction already, and that is not the same plan as Native Jetpack.

In the Native Jetpack plan the entire build process will be redundant and you therefore will be able to use Jetpacks without any modification.

Please read the JEP if you’d like to know more.

Third Party Modules

Working in parallel to the Native Jetpack project described above is a project to support Node dependencies, this is bug 935109.

In this plan we will drop the old custom made third party dependency support that was developed for Jetpack back in late 2009 early 2010 and just use NPM instead. This makes a lot of sense because almost all of the interesting CommonJS modules exist on NPM at the moment.

Note I did not say we are binding ourseleves to NPM, because we are not, if there is another popular CommonJS package manager then we will utilize that too. The plan is really merely to utilize what is popular.

Rapid Development and Collaboration

Two of the initial goals for the Jetpack project was to make extension development easier and more collabortive. As far as I could tell these were the main reasons why the Add-on Builder was developed. I voiced my concerns about the idea back in January 2010, and in my opinion it failed to achieve it’s mission, and was too expensive, and now it will be shut down.

I do not make decisions on the Jetpack team, I only give my advice like I have since I was a user in 2009 and a ambassador in 2010, and a contributor in 2011 onwards until I was hired to work on the team. So I do not know what the plan is here now, and my ability to predict this stuff is clearly lacking, and there are many options, but this is my hope given the above seems pretty much agreed to at this point.

Once the Native Jetpack plan becomes a reality, there will be no need for special tools to build Jetpacks, one only needs to zip a Jetpack, therefore a large number of options become much easier to implement, and there is very little standing in the way of a lone developer to make their own solutions here, and I hope to see many options bloom and the best ones prosper. However Mozilla should design and implement a solution which is built-in to Firefox in my humble opinion, and my hope is that it looks something like the following.

A dead simple, featureless editor like Scratchpad is available to be used for quickly editing/adding/removing add-on files. That is it. For collboration people will use NPM, Github, Bitbucket, or whatever is popular.

This should be much easier to build, maintain, and pay for than Add-on Builder was I should think (also more useful).

Conclusion

The future is near, and a few team members and I are writing the codes for it now, so please voice your questions and concerns ASAP in the Jetpack mailing list.