Determining the Angular Core Version Dependency of an AngularJS Module

Handsontable JavaScript Spreadsheet Most popular component for web apps


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 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):

  1. Check the bower.json (usually in dependencies)
  2. Check the package.json (usually in dependencies)
  3. Check inside the HTML of the demos
  4. Check the Gruntfile.js
  5. Check the open/closed issues for information
  6. Check the releases for information
  7. Check version.txt
  8. Check yourself, then wreck yourself.

Real World examples of Angular Modules

Bower.json & Package.json

angular dependencies in bower
angular package.json dependencies
ngbootstrap dependencies


grunfile ng dependencies

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 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!).

modules have releases for previous versions of AngularJS

I’d probably recommend the following:

  1. Search the repo for any mention of backwards support for your version.
  2. Search for demos which include the version your looking to use the module with.
  3. Try it yourself.
  4. 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!

ng version stats

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:

  • exact
    • “angular” : “1.3.0” (exactly version 1.3.0 required)
  • > greater than
    • “angular” : “>1.3.0” (version greater than 1.3.0 required)
  • >= equal or greater than
    • “angular” : “>=1.3.0” (version equal or greater than 1.3.0 required)
  • ~ approximately
    • “angular” : “~1.3” (version approximately 1.3 required)
  • ^ compatiable
    • “angular” : “^1.3” (compatible with version 1.3)
  • .x wildcard group
    • “angular” : “1.3.x” (version in range 1.3.[0-9] required, ie 1.3.9 is ok, 1.2.9 not ok)
  • .* wildcard any
    • “angular” : “*” (any version)
  • ||, – or ranges
    • “angular” : “1.3.x || >1.4.0-beta.0” (version 1.3.x required OR beta [pre version release] greater than 1.4.0)
    • “angular” : “1.0.0 – 1.4.0” (version between 1.0.0 and 1.4.0 required)
  • latest
    • “angular” : “latest” (latest version required)

So where do you put your supported version?

Ass suggested by Angular Seed:

  1. Put your AngularJS Core dependency in either bower.json if your using bower.
  2. Or in package.json if your using npm.
  3. Full stop

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

updating angular using npm or bower

Are there any other tips?

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

  1. 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.
  2. 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.
  3. Try to be as specific as you can about what versions you support.


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!

Sam Deering

Sam Deering

Sam is a web developer, online entrepreneur and investor. In his spare time he enjoys coding, playing chess and sharing what he learns with others.

2 thoughts on “Determining the Angular Core Version Dependency of an AngularJS Module

Leave a Reply

Your email address will not be published. Required fields are marked *