It because package management in JS is complete garbage. I can't believe people actually like using Bower or Browserify or JSPM or any of it. While NPM for Node has some scaling problems, at least it just works for the simple cases. I've never not had problems with the client-side JS package systems and managers.
So package adoption is hard because of this. If you make it a pain for implementing developers to use your code, they're more likely to just write their own code.
That's why I think the old style ala jQuery or Google Maps API of packaging everything manually as just namespacing-objects still makes the most sense, with the fewest tradeoffs. You give the user a single, minified JS file to either copy or reference on your CDN. It's a least-common-denominator solution and it lets the implementing developer figure out how to fit it into their workflow.
In general I just use npm... I don't use bower or jspm... for that matter, I don't think browserify where needed is so bad.. there's also options with babeljs, which I'm liking more and more.
A base set of packages, for your external functionality, your core (shared functionality) and the rest makes a lot of sense, and isn't that hard to do. In the end it's pretty easy to reason about, and with sourcemaps and better build tools it's easy to use. Though having to have a watcher or build process when JS changes takes some getting used to... if you're used to compiling server code, it really isn't bad...
So package adoption is hard because of this. If you make it a pain for implementing developers to use your code, they're more likely to just write their own code.
That's why I think the old style ala jQuery or Google Maps API of packaging everything manually as just namespacing-objects still makes the most sense, with the fewest tradeoffs. You give the user a single, minified JS file to either copy or reference on your CDN. It's a least-common-denominator solution and it lets the implementing developer figure out how to fit it into their workflow.