(Original discussion as of July 2014)
The current packaging of Infusion is rather monolithic and old-fashioned. Modern JS users require a variety of builds through a variety of formalities -
i) A variety of different module loaders and contexts, e.g. the plain browser, node.js, require.js in the browser, AMD and non-AMD aware module loaders, CommonJS module loaders
ii) A variety of different elements inserted in the build - framework-only, a custom mixture of components, a custom pattern of 3rd-party dependencies, some of which may be in common (e.g. jQuery and jQuery UI etc.)
iii) A variety of different treatments (concat/minification, custom boilerplate - this one feeds back into i)
"bower" is a particularly interesting current environment. Things in its favour are that it is extremely easy to get to grips with and has a completely static structure (a "module" is simply a git repository) and flat checkout structure. These same are the key points against it also - for example, it supports no plugin structure nor alternative technologies for repositories (for example, plain HTTP). It's quite possible it may cease to be "flavour of the month" before long and give way to a more sound solution covering several more of the deployment points and scenarios (especially more sane treatment of 3rd-party/multiply occuring dependencies) but the current proliferation of "crazy bananas" module loaders shows no signs of bringing this about very soon.
As well as considering the use of bower, we considered strategies for modularising "Infusion" or "an Infusion artefact" and how this modularisation should interact with our current git repository structure.
The world has moved on somewhat since this original discussion. "bower" has largely become derelict, and we have a lot more experience of the really obstructive bureaucracy of working with multiple git repositories. The general movement, as per the increasingly popular "lerna" package - https://github.com/lerna/lerna, is to work with single, large git repositories ("monorepos") containing multiple npm packages. Interestingly we already had partial experience of this as part of a pattern we developed in the GPII's projects, but this pattern could be taken further than we did and supported with a bit of tooling.
After discovering the insufferable problems npm poses to those trying to work with scripts in nested packages as part of https://issues.fluidproject.org/browse/FLOE-484 we convened a small meeting to revisit our modularisation issues. Notes were taken at https://pad.gpii.net/p/infusion-module-discussion-oct-4-2016-okg4ntt which are wikified below: