bower install backbone#1.1.0
Which will download backbone version 1.1.0 and his dependencies into the directory
./bower_components/backbone/. All Bower packages are downloaded into
Bower is handling versions and dependencies but It does NOT wire the JS components into your project. And that’s OK! It doesn’t force you to a specific directory structure. That’s all up to you.
During our integration work we had to crawl the bower registry and GitHub to get the meta data in our MongoDB / ElasticSearch backend. Here are some interesting numbers I would like to share with you.
All registered bower packages are available through this JSON file:
Each element in the array contains the name of a bower package and the URL to his repository. At this time the list has 8504 entries. Only 47 URLs don’t link to GitHub.
Some of the 47 URLs link to Bitbucket and funny entries like 192.168.0.131 🙂
We consider a bower package valid if both of these conditions are true:
- The URL still exists and is publicly available.
- The repository contains a valid bower.json or component.json file.
From the 8504 packages 2515 we couldn’t validate. That means either the repository doesn’t exist anymore or we couldn’t find any bower.json file or the the bower.json file was not valid JSON. 5989 packages had valid bower.json files.
More than 900 registered repositories simply don’t provide a bower.json file. Other ones provide a bower.json file but it contains errors. The most common error is that there is a comma to much or to less in an array definition.
From the 5989 packages we could validate, 1194 don’t have any version tags in the associated git repository. 4795 packages provide at least one tag.
Having a package registered on a package manager without fixed version/tag is a bit useless. From all 8504 registered packages only 4795 offer a valid bower.json file and some tags on their repositories.
The bower specification describes exactly how a valid package has to look like. One of the points for the name is: “Lowercase, a-z, can contain dash or dot but not start/end with them“. But actually 495 packages do have uppercase characters in their name. That alone is not dramatic. But some packages are registered with the same name. For example the “scroller” package. It is registered as “scroller” and “Scroller”. Two different GitHub repositories with almost the same name. The only differentiator is the lowercase/uppercase S in the beginning. We were able to find 34 names where collisions occur if you force lowercase names.
There is a very simple reason for this numbers. There is currently almost no validation on the submissions. But user authentication and package validation is already on the todo list of the Bower team. I expect many improvements in the next months. However, launching a package manager without any kind of validation was maybe not the best idea.
I don’t wrote this article to keep you away from Bower. The people behind the bower project are smart guys and very responsive on Twitter. They are continuously improving. And by the way, it’s all open source. Everybody can send a pull-request to improve the validation. I already send a pull-request for the name validation.
Having some kind of versioning for frontend development is very important. Otherwise you just download some CSS and JS files from the Internet and put them into your project. After a couple weeks most likely you don’t even remember which version of backbone your are using. Imagine doing that with your ruby gems or python libraries! Developers should take versioning of their frontend code as seriously as they do for their backend development.
If you are a Ruby on Rails developer you should check out this page https://rails-assets.org/ for rails – bower integration.
If you wanna know more about how to monitor a bower.json file or how to get a dependency badge for your bower project you should check out this blog post about our Bower integration.
What are your experiences with Bower? Leave a comment here or contact me on Twitter. I would like to hear your opinion to this topic.