I'd still love to know how I could have found the place in our source code that caused this issue, but I have since been able to find the problem manually.
There was a controller function declared on the global scope, instead of using a .controller()
call on the application module.
So there was something like this:
function SomeController( $scope, i18n ) { /* ... */ }
This works just fine for AngularJS, but to make it work right with mangling, I had to change it to:
var applicationModule = angular.module( "example" );
function SomeController( $scope, i18n ) { /* ... */ }
applicationModule.controller( "SomeController", [ "$scope", "i18n", SomeController ] );
After further tests, I actually found instances of more controllers that also caused issues. This is how I found the source of all of them manually:
First of all, I consider it rather important to enable output beautification in the uglify options. For our grunt task that meant:
options : {
beautify : true,
mangle : true
}
I then opened the project website in Chrome, with the DevTools open. Which results in an error like the one below being logged:
The method in the call trace we're interested in, is the one I marked with an arrow. This is providerInjector
in injector.js
. You're going to want to place a breakpoint where it throws an exception:
When you now re-run the application, the breakpoint will be hit and you can jump up the call stack. There will be a call from invoke
in injector.js
, recognizable from the "Incorrect injection token" string:
The locals
parameter (mangled to d
in my code) gives a pretty good idea about which object in your source is the problem:
A quick grep
over our source finds many instances of modalInstance
, but going from there, it was easy to find this spot in the source:
var ModalCreateEditMeetingController = function( $scope, $modalInstance ) {
};
Which must be changed to:
var ModalCreateEditMeetingController = [ "$scope", "$modalInstance", function( $scope, $modalInstance ) {
} ];
In case the variable does not hold useful information, you can also jump further up the stack and you should hit a call to invoke
which should have additional hints:
Prevent this from happening again
Now that you've hopefully found the problem, I feel that I should mention how to best avoid this from happening again in the future.
Obviously, you could just use the inline array annotation everywhere, or the (depending on your preference) $inject
property annotation and simply try not to forget about it in the future. If you do so, make sure to enable strict dependency injection mode, to catch errors like this early.
Watch out! In case you're using Angular Batarang, StrictDI might not work for you, as Angular Batarang injects unannotated code into yours (bad Batarang!).
Or you could let ng-annotate take care of it. I highly recommend doing so, as it removes a lot of potential for mistakes in this area, like:
- DI annotation missing
- DI annotation incomplete
- DI annotation in wrong order
Keeping the annotations up-to-date is simply a pain in the ass and you shouldn't have to do it if it can be done automatically. ng-annotate does exactly that.
It should integrate nicely into your build process with grunt-ng-annotate and gulp-ng-annotate.