The newer JavaScript UI work is based on building CommonJS/Node style JavaScrpt "bundles" that can be loaded in the browser. js-modules adds to that setup by allowing us to break out these bundles such that they can be slimmed-down to not include common dependencies (e.g. jQuery) i.e. we "externalize" these common components (framework libs).

At the moment, this externalization process works by us creating Jenkins plugins (HPI) for these framework libs (see js-libs) and then linking in these external bundles where used.

As an example of this, see the step-04-externalize-libs sample plugin ("How it works" page). You'll see that there ends up being a number of additional moving parts i.e. we need to:

1. define a maven dependency
2. add an extra instruction in the gulpfile.js

Personally (tfennelly), I can live with this and do not think it'll be a huge deal, but I do agree with kzantow that it would be nicer if developers did not need to do this at all (it's something that annoys him intensely).

Keith outlined one possible way of making this work that would definitely be worth investigating when we have a chance. Basically, it would be about keeping everything in "node land". Taking the bootstrap framework lib as an example, instead of building a HPI, we could generate a js-modules bundle of `bootstrap-detached` and publish it to the NPM registry with `bootstrap-detached` itself i.e. the published version of `bootstrap-detached` would include a js-modules bundle version of "itself". it would also somehow need to include copies of the bundled versions of it's dependencies (something we'd need to work out).

Would be great if we could find an "easy" way of making this work, but it's not a blocker for anything.