Type: New Feature
Affects Version/s: None
Fix Version/s: None
Leading on from
FLUID-5503, there is scope for a more fully featured module system, capable of taking on the tasks of module location and resolution throughout a hierarchy.
Notes describing this implementation and its motivations are at http://wiki.fluidproject.org/display/fluid/Notes+on+the+Infusion+Module+Loader
i) Find modules conforming to a specification automatically throughout a hierarchy, without requiring explicit "require" statements for linkage - this makes it easier for 3rd parties to introduce their code into a GPII, for example, without forking the codebase
ii) Support for "linking" module resolution requests to a particular path during development - this eases the pain of working with multiple related modules without having to round-trip them all via git and npm
iii) Coordinate access to shared modules during installation and loading - for example, standard npm semantics force installation of multiple copies of infusion which are a hazard during standard node module loading, requiring a custom grunt task "grunt dedupe-infusion" to eliminate them as an extra build step. We will construct custom grunt tasks and packaging to replace the use of npm for these tasks, which will rely on this module loading code during build time.
Two of the prerequisites described in the wiki notes (fluid.global, and module registration system) have already been achieved as part of the