Seriously though, it's a non-problem now. There is no way I'd go back to anything else. Webpack and browserify are the only way to go. </religion>
Yes, there is a certain purism to doing your own modules and IIFEs and JS, but it's like claiming that code is only fast when it's asm. </realcoders>
Besides it can all be optimised out if you add the closure compiler plus relevant comments </nobodyactuallydoesthat>
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.