The landscape
Bower is one of most popular packages management tool, especially for frontend assets like Javascript and CSS. Other strong contender areĀ composer, npm and webpack. But Bower shines in simplicity to get going. Bower itself is installed via npm, there is also a reimplementation in PHP called BowerPHP.Ā We use bower on some productsĀ however in my team, Kleine Eule, weĀ found one particular important issue with bower ..
The problem
The main issueĀ we found was that we wanted to track exact version numbers of installed packages. Pin pointing exact version numbers of a package (ex: 1.6.7) allows us to better synchronize production between multiple developers. Further more it allows us to track potential known vulnerabilities in thoseĀ versions. It also makes theĀ migration to new versions a conscious choice. Ideally of course you do not want to have to manually pin the versions but instead want Bower to do this automatically.Ā There is a pull request attempting to solve thisĀ issue, but it didn't attract much attention from core developers. A side benefit lock file, as proposed in the PR, could also helpĀ improve install performance.
The āsolutionā
We attempted to solve this problem in another manner, using custom resolvers.Ā Custom resolvers areĀ a way to extend bower functionalities. Since it doesn't require integrating to Bower core we would not needĀ the core devs to integrate it. Essentially we wanted to implement the behavior of theĀ composer.lock file. ItĀ allows us to pin point installed versions in a very elegant manner automatically.Ā There is similar a approach in npm called shrinkwrap.
The fail
However as we were looking at how we would want our custom resolver to work, we found out that Bower's core functionalities Ā are fundamentally broken.

The takeaway
It seems like Bower was designed to be unpredictable and at least for a package management we really need a deterministic system. So essentially Bower is great if you are a single developer that uses FTP for deployment but for all other cases its default behavior is simply broken. Trying to fix this via a custom resolver would mean essentially totally changing its entire behavior.
kthxbye
As a result we, team Kleine Eule, decided to just recommend everyone to ditch Bower and instead toĀ migrate future projects to use npm instead of Bower as the easiest migration path.