How should we manage front-end dependencies?

We use NPM and bower as package management tools and still commit all of the dependencies (but not dev-dependencies) to the VCS as Mark alluded to above.

Package management allows us to easily upgrade in this instance, without losing out on easily transferable repositories for use by junior/external developers.

Wow, this is a complex subject. After spending a little time looking into the options I'm leaning more and more towards using composer where possible.

Pros would be:
1. No new tools to learn
2. RequireJS support out of the box for anyone that wants to use it
3. Frontend components (e.g. jquery) can be overridden/upgraded/managed/forked/etc centrally from the project composer.json. I can't find a way to do the same with with bower or npm since they don't know about silverstripe modules. It looks like each module would need to manage it's own packages separately.

Cons:
1. As Sam mentioned frontend components are a lot thinner on the ground on packagist than npm/bower.
2. All components are installed to /components/ in the project so we'd have to include those components in the silverstripe-installer package and/or push more people towards composer.

HOWEVER, this seems more and more like a "nice to have" thing to me but not worth pursuing for now. I certainly don't have time and I wouldn't want it to hold up 3.2.

@steviemayhew you may be able to speak to some of that better out of your experience.

Thinking out loud, excuse any grammar and brain-farts.

Imagine we are using composer and front-end components like jQuery gets put in a 'site wide folder' like /vendor/jquery/jquery...

SS framework requires version X
but module Z requires version Y
= composer would refuse this setup.

One would argue that this currently doesn't work, but it does works when separating the jquery versions between front-end and back-end.

In this case one component would stop another component from having an up to date version of jquery.

Stig, that's the most convincing argument against this yet. The status quo does make it relatively easy to use a different version of jquery on the frontend and backend.

I'd say stability overrides anything. If the versions change too often maintainability becomes painful. Whenever I work on modules I try to make sure I am working within what is bundled (for the admin side). It's quite common to have to work within the version a system is built with.