There's a better way. Anywhere Angular expects a function it will take an array as well. The array can be the usual list of dependencies and a function.
Can someone explain why this is broken by minification? I'm not seeing it. Something about the parameter names ($scope, $attrs, $element) being re-written by the minifier? Does Angular require them to be named in a certain way?
Angular makes extensive use of dependency injection. The unit of DI in Angular is called a provider. A provider is a function that can be injected and takes it's dependencies as arguments. The function then performs a provider role specific action when invoked.
The specific problem here is when the developer relies on Angular to infer dependencies. Angular does this by converting a function reference to a string which returns the full source of the function. It then parses the function parameter names and resolves those as dependencies.
The canonical example of this is an Angular controller (which is one of the provider roles).
When angular parses that it sees a symbol named 'a' and tries to resolve that as a dependency.
As I mentioned elsewhere, everywhere Angular takes a function as a provider it also takes an array. The array is expected to be a list of dependency named and a function. I've found that the DRYest way to declare a provider is like this:
1. After gzipping, which is done transparently by almost every server/client, the payload size savings from minification really aren't all that compelling.
2. Minification makes debugging your production code harder (digging through minified source) or more laborious (working with a source map).
3. Obfuscating your code runs antithetical to the open nature of the web
Here's a working version: http://jsbin.com/onevaz/1/
For what it's worth, I agree that the docs need to reflect this.