Looks great, thanks!

Awesome thank you!

Any chance for a version bump and publish to NPM?

to make that even more compliant with best practices, module.exports should not export the module itsself, but the name of the module, i.e. module.exports = "duScroll" or module.exports = duScroll.name

I agree with @ctaepper that's how I do it for myself, but I find people tend to export the module itself.

@oblador do you have a preference?

those people just don't know better yet... :)

Using angular with browserify makes me a bit uncomfortable because they both try to solve the same problem. Haven't read any best practices for this and am not too opinionated, personally for my angular projects I export both :-) Somehow feels weird for an AMD to only return strings.

Got any links on the matter?

Finally, to match the convention for CommonJS set up within Angular, you’ll need to expose the string that people use to load your module. You’ll do this using module.exports. Note, this is a convention that Angular uses, and it doesn’t necessarily apply to other front-end projects.

see http://blog.npmjs.org/post/114584444410/using-angulars-new-improved-browserify-support

basically like this

// require the module
var scroll = require('angular-scroll')

// and add it as dependency to your app
angular.module('app', [scroll])

@ctaepper: As of 0.7.4 this is now the behavior. If you want to access the module itself then do a require('angular-scroll/angular-scroll').

👍

It's actually 1.0.0 now since it broke someone's installation :-)