Over the last few months of last year we have been crafting away and exploring many new exciting frameworks and technologies. So many to mention...... but our core stack as of late has mostly consisted of node.js. As people of node.js know the npm package manager that is bundled is a fantastic tool to resolve dependencies for the project in question.
With this in mind myself and Stu have been busy hard at work with a large client in the finance sector and looked to 'resolve' our client side dependencies in an equivalent manner. We had a look around at some of the options and for our use case the same two kept cropping up.
The folks over at the Twitter Engineering team have been hard at work again and built Bower as a client-side package manager. It allows you to resolve your dependencies via a component.json file and install the relevant git paths as required. This approach is at a lower level than other alternatives it doesn't limit you to any transports, ultimately you decide how you wish to deliver your packages client side.
The great thing is that you can just point to git paths and you are away without dependencies on other people to own and manage the updates of packages that exist. From the experience we had working with Jam.js I suppose it might also be fair to say that it would have taken less "tinkering time" to get the transport with require.js working client side along side some out of date package versions we couldn't update.
Jam.js is a package manager with a different spin in that it will install packages from a core jam.js package repository, resolve dependencies and using AMD / require.js to configure transporting your packages to the client. The configuration for the packages are defined and are stored within your standard package.json file.
There is a down side that is quite commonly raised with the fact you upload a package to a repository separated away from github. Once a package is uploaded the owner is the only person in which they can update it (unless the owner adds other users). There is an option to setup your own repository and have jam search the core repository in addition to the one you create, to me this is a big limitation in regards to package management.
Package management should, in my opinion, be sourced from one place in that it is concise, self managing, effective to install and configured to deliver to the client in the best possible manner. Jam.js for me meets three out of four in this criteria.
I have started a pull request to try and help with the update of packages via pull requests. The idea is taken from github / git and allowing users to submit pull requests to repositories. The initial implementation of this feature with a description and can be found at: https://github.com/caolan/jam/issues/128
We made the choice of Jam.js for out project as it suited our needs to have require.js be configured and setup up as the transport to the client (once we cracked some of the require.js path configuration). All you need to do is quite naturally add your jam dependencies within your package.json and type on the command line jam install just like npm install and away you go.
It is not to say we will never use Bower as it does it's job well and the fact it is lower level may suit other projects where transport via AMD is not a preference. We may also switch if we find the package management and the central package repository not being kept up to date by community, this is where Jam.js can and may fall down.