It should be possible to use jpm in Firefox as an add-on dependency

[erikvold]

No description provided.

[jsantell]

What are the benefits and uses of this? Just a testament to consuming node code? I'm not sure about all the dependencies we have being able to support it

[erikvold]

There are a few add-ons that build add-ons, and it would make sense that they would re-use jpm code instead of having to rewrite the wheel here. Examples: Scriptify and https://github.com/ZER0/theme-my-site

[jsantell]

Good point -- we should also ensure that we expose a good API for node users (that Scriptify/theme-my-site would use), in addition to our CLI CFX replacement API

[jeffgca]

So, could we build a low-level library in the SDK that allows you to automate what the AOM is going to do for native jetpacks?

eg:
var builder = require('sdk/utils/addon-builder').Builder({} /* some options */);

// build a native jetpack
builder.build(directory, [outputfile]);

// build a native jetpack and then load it
var promise = builder
  .build(directory, [outputfile])
  .load([callback]); // allow promise or callback pattern?

[jsantell]

I think this would be more like a library in JPM itself so that other addons could use it:

// My Addon-Generator
var jpm = require('jpm');
jpm.build(dir, outputfile).then(function () {
  notification.alert('Addon Built!');
})

While there are these two addons that currently generate other addons, how common is this? I'd imagine it'd probably be easier creating addons in memory (static files for the addon, and pass in strings for js/css, and then zip). If this is a requirement, it'd also influence what dependencies are used in jpm, as they will all need to be working with node loader, etc. and size constraints (as node modules are less concerned about file size compared to front-end dependencies or add-ons).

Of note, it doesn't look like any of the dependencies are using C-bindings atleast. OTOH, we're looking at 19MB in deps for JPM.

I think that all of our other goals (jpm/aom goals of no 'compilation' step, loader being able to load any non-C-bound module) would lead us to the goal of having jpm inside another addon, but is a side effect, rather than a goal itself, as jpm inclusion in an addon would only provide extra options for --verbose, etc., since lack of compilation step only leaves fs writing and zipping. Also with CLI additions to FF/AOM, this goal would be redundant then

[jeffgca]

"like a library in JPM itself" I agree except that add-ons that want to create add-ons should not need to use a 3rd party module, we should give them an in-product path to do that before they go ahead and re-invent the wheel. The ability for an add-on to leverage the changes in AOM in a nice way feels to me like a core capability.

[jsantell]

This would also require having node API shims within SDK so that require('fs') -> require('sdk/io/fs') when in jetpacks