I'm not 100% sure on the positives. Here's a few negatives
You often end up adding dependencies to 3rd party servers/endpoints that might
not be stable.
I've had it happen with bower that the repo of some dependencies
was deleted or moved. So a new dev comes along, clones my repo, types
bower install and gets errors for un-accessible repos. If instead I
had checked in the 3rd party code into my repo that problem disappears.
This is solved like the OP suggests if you're pulling deps from copies
kept on a server you run.
Harder for noobs.
I work with art students with very little command line experience.
They make art with Processing, arduino, Unity3D, and get by with very
Steps because of bower
- Download Zip of repo from github (notice that's on the right of every
repo on github. Because they don't know git)
- Download and install node (so we can run npm to install bower)
- Install git or msysgit (because bower requires it and it's not installed
on many students' machines)
- Install bower (
npm install -g bower)
bower install (finally to get our dependencies)
Steps 2-5 can all be deleted if we just check in the files to our github repo.
Those steps likely sound super easy to you and me. To the students they were
very confusing and they wanted to know what all the steps where and what
they were for which might be good learning possibly but was entirely
orthogonal to the class topic and so likely quickly forgotten.
It adds another step when pulling.
It's happened many times I do a
git pull origin master and then test my
code and it takes 5 to 10 minutes to remember I needed to type
to get the latest deps. I'm sure that's easily solved with some pull script
It makes git branching harder
If 2 branches have different deps you're kind of screwed. I suppose you can
bower install after every
git checkout. So much for speed.
As for your positives I think there are counter examples to each of those
Eases the process of distributing and importing shared modules, especially version upgrades.
vs what? It's certainly not easier to distribute. Pulling one repo instead of 20 is not easier and is more likely to fail. See #1 above
Removes shared modules from source control, speeding and simplifying checkouts/check ins (when you have applications with 20+ libraries this is a real factor).
Conversely it means your dependent on others for fixes. Meaning if your deps are pulling from a 3rd party source and you need a bug fixed you have to wait for them to apply your patch. Worse, you probably can't just take the version you want plus your patch, you'd have to take the latest which might not be backward compatible with your project.
You can solve that by cloning their repos separately and then you point your project deps to your copies. Then you apply any fixes to your copies. Of course you could also do that if you just copy the source into your repo
Allows more control or awareness of what third party libs are used in your organization.
That seems arguable. Just require devs to put 3rd party libraries in their own folder under
<ProjectRoot>/3rdparty/<nameOfDep>. It's just as easy to see what 3rd party libs are used.
I'm not saying there are no positives. The last team I was on had > 100 3rdparty deps. I'm just pointing out it's not all roses. I'm evaluating if I should get rid of bower for my needs for example.