I’m not 100% sure on the positives. Here’s a few negatives

1. 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.

2. 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
   little tech knowledge. They wanted to use some HTML5/JavaScript I wrote.
   Steps because of bower

   1. Download Zip of repo from github (notice that’s on the right of every
      repo on github. Because they don’t know git)
   2. Download and install node (so we can run npm to install bower)
   3. Install git or msysgit (because bower requires it and it’s not installed
      on many students’ machines)
   4. Install bower (npm install -g bower)
   5. 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.

3. 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 bower install
   to get the latest deps. I’m sure that’s easily solved with some pull script
   hook.

4. It makes git branching harder

   If 2 branches have different deps you’re kind of screwed. I suppose you can
   type 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.

Take a look at The Twelve Factor App

In particular read about what they have to say about dependencies. You will notice that good design provides a declarative mechanism for locating dependencies, in Java this is often realised through Maven. Ivy and NuGet work fine, but Maven is currently the leader in the field and Ivy is decidedly hard work.

If you adhere to the Maven release process (develop snapshots until a formal release is ready, never try to overwrite a previous release, use a proper repository manager like Nexus or Artifactory) then you should have a build process that hums along nicely.

Once you have a solid declarative build process in place, it opens the door to other good practices such as Continuous Integration with Jenkins, Continuous Code Analysis with Sonar and you’ll find yourself looking for a better version control branching strategy using git.

Each of the above builds on the core that is Maven. These days, it is pretty much a no-brainer decision.

And the #1 item on our top 10 list is …

(drum roll)

Every developer builds with exactly the same versions of all the dependencies, so you never have to wonder what to deploy into production.