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.
Proposals:
1a:
i) Fully modularize Infusion at the level of git repositories
ii) Use bower to express dependencies amongst modules that were formerly known as Infusion
iii) Provide a Grunt plugin that helps users produce a manageable single-file Infusion build from their various bower depenencies
1b:
i) Fully modularize Infusion at the level of git repositories
ii) Use bower to express dependencies amongst modules that were formerly known as Infusion
iii) Commit the build artifacts for each module into its Git repository
2a:
i) Don't modularize Infusion
ii) Create a single repository, called infusion-bower containing "common builds"
a) All of Infusion
b) Framework-only
c) UI Options
...
iii) Come up with some kind of post-commit workflow that allows us to easily:
a) produce the above-mentioned builds
c) push them to the Infusion-bower repository
2b:
i) Modularize Infusion into:
a) framework ("infusion")
b) all the components ("infusion-ui")
c) jqUnit + IoC testing framework
** What about circular dependencies?
ii) Create bower repositories for:
a) framework
b) infusion-ui
iii) Come up with some kind of post-commit workflow that allows us, for ii.a and ii.b to easily:
a) produce appropriate builds
b) push them to the -bower repositories
** This will likely involve a grunt plugin
** Minified builds should be ditched, and should be the responsibility of the user of builds
** How should we handle tags?
3: We could adopt a WACKY NAMING CONVENTION, together with some kind of scheme for automatically publishing artifacts which match a specification into a CDN
THAT IS, for each possible build profile of Infusion there corresponds a unique and easily and publically determinable stable global name - a request to that URL either fetches a pre-built artifact cached there, or else triggers the build process in order to populate it
As in ---- ***NIXOS***!!
Summary:
1. Bower isn't a sufficient package manager for large, modularized systems where a user is able to freely choose parts of the larger system to include in their application (e.g. the choice amongst a set of Infusion components, or jQuery UI widgets, or Angular modules, or whatever)
2. The model where modules are always directly tied to Git repositories is inappropriate because -
i) build artefacts are derived FROM material which is version managed, it is not appropriate to version manage them themselves (a.k.a. it's noisy and annoying to have your build artifacts under version control)
ii) there is no model for acquiring a part of a github repository either via git or its REST API - each user of a build system just wants ONE configuration of build artefact rather than having a collection of them pushed to them most of which they will ignore
a) There are 2^N build combinations based on N binary choices - and there is in reality a very "long tail" of users who might commit each other to checking out build artefacts only 1 of which they need
3. Until either a suitable web package manager emerges or we introduce one ourselves (which we're not going to do any time soon), we prefer proposal #2 because it is the least disruptive to Infusion's repository status quo while enabling many users to quickly "bower install" and use Infusion, at the cost of an additional build/commit stage for committers to Infusion
THOUGHTS that were not captured in the above:
- A big risk is our use of raw commit hashes in several venues, esp. in JIRAs. The traditional use of git filter-branch would destroy all of these. A possible route around this is to simply clone our infusion repo into infusion-framework and infusion-components, and simply git rm the mismatching files. Our repo has not become so large that this doubling would be prohibitive
- Fully modularising infusion into a one-repo-per-component repo would be extremely prohibitive. Our directory structure currently consolidates artefacts by type and not by component - e.g. all jQuery UI plugins are sourced from a central location, all tests are held in their own area, etc. Reorganising all of this would make matchwood of our git history as well as depending on really indomitable performance by our hypothetical build/module system in allowing us to consolidate dependencies which do indeed end up being shared.
- We really don't release enough, and splitting off the framework might allow us to make perhaps more frequent releases of at least that given its (internal) QA consists of just running its tests. However, a framework build can't be considered desirable unless it has been validated against most or all of our "live" users ("the components", the metadata tool, the video player, kettle, the GPII, etc.). This is another route to ease off our current recidivist reliance on git hashes and become a slightly more recognisable citizen of the npm semver-toting club.