Determining the Angular Core Version Dependency of an AngularJS Module

Get Your Free Angular 2 Book Chapters

As AngularJS continues to grow, so do the versions and likewise the number of open source modules. This is great news for the library and AngularJS coding community! But sometimes it can be a pain when trying to find and use “reusable” modules. So I decided to take a closer look at what AngularJS module developers are doing (with regards to catering for the core versions of Angular) and see if I can provide any useful information to improve the quality of the modules, documentation or even just to raise some awareness.

How do you find the Angular Core dependency of an AngularJS Module?

If you are a junior-mid developer your first thought might be to look for the core library dependency in the README of the Github repository. But, since less than 5%* of the open source AngularJS Modules even mention the core dependency versions in the Readme.md you might come unstuck there. Next you might look at the bower.json and/or package.json and check the dependencies list, this is more likely since 36% of modules have specified it in either bower.json or package.json (*see below for source of stats). Then last but not least you might get lucky and find it in the Gruntfile.js or hidden in the HTML of the demo example. So this is where you might look (ordered by most likely):

Check the bower.json (usually in dependencies)

Check the package.json (usually in dependencies)

Check inside the HTML of the demos

Check the Gruntfile.js

Check the open/closed issues for information

Check the releases for information

Check version.txt

Check yourself, then wreck yourself.

Real World examples of Angular Modules

Bower.json & Package.json

Gruntfile.js

AngularJS backwards support

Backwards support can sometimes be a tricky one (even more so with AngularJS 2.0 just around the corner as it looks a lot different in the way it works). You might find some modules have releases for previous versions of AngularJS and some simple don’t support them. Some modules specify a minimum version but fail to maintain this when new versions of Angular get released (the bower.json specifies the latest release version as the core dependency). The backwards support might be noted in the README.md which refers to a release version or tag. But not always. So how do developers find out if a module has backwards support? example: angular-http-auth (just a random example, no hate I promise!).

I’d probably recommend the following:

Search the repo for any mention of backwards support for your version.

Search for demos which include the version your looking to use the module with.

Try it yourself.

Or… like I usually say, these are not tears, I got something in my eye.

I’m interested to hear what people think about this! (please leave a comment).

Give Me More Stats!

So I decided to run some tests on a set of the most popular AngularJS Modules (around 1,300 including some Filters, Services and Frameworks) to see what they are doing about mentioning supported versions of the ng core. Here is a snapshot of the results as at 28/06/2015 (click on the image to see more recent results). In summary 828/1300 (64%) did not specify the supported core version for the module. That’s over half!

What does angular: “~1.2.11” mean?

To increase your knowledge of versioning, I’ve listed below roughly what each group of versions mean using the Semantic Versioning Syntax (semver). In summary and example:

So where do you put your supported version?

Put your AngularJS Core dependency in either bower.json if your using bower.

Or in package.json if your using npm.

Full stop

I’m interested to hear what people think about this! (please leave a comment).

Are there any other tips?

I would suggest to (and welcome to comments on this please):

Be more specific about the versions of AngularJS your module supports. This way you can save other developers time in determining support and less apps will break when dependencies update.

Provide backwards support for your modules in the form of a release or tag so that apps depending on older versions can still use it.

Try to be as specific as you can about what versions you support.

Conclusions

Although there is a huge number of open source AngularJS Modules that have been coded in a multitude of different ways (in terms of structure, dependencies, documentation, testability etc…) we can all contribute to get us back on the right track so we can drive the web forward with modules & directives and create better AngularJS web apps! Feel free to comment would love to hear your thoughts on this and how we can solve it!

Angularjs4u.com is not endorsed or certified by AngularJS. All AngularJS logos and trademarks displayed on this blog are property of AngularJS.
The views expressed on here are purely to help other developers use AngularJS.