It's Not Hard: Making Your Library Support AMD and CommonJS

All of my projects using the UMD-wrapper approach are published to npm, so it definitely does not stop you from publishing/utilizing it. Both postal.js and machina.js are examples of this. I can understand why using a UMD feels like it complicates things. I find it more annoying than complicating, personally. John-David Dalton (dev behind Lodash) had some great comments along these lines though when he was on the JSJ podcast - it's about helping developers. And having the ability to support CJS and AMD (in addition to plain globals) doesn't cost much in terms of effort or code, and the resulting win for you and people using your project is worth it, IMO.

Replies

Ash 3802 days ago. link 1 point ▲ ▼

Ah yes, I remember that episode of JSJ. UMD makes perfect sense for something like Lodash, where ease of use and portability is really important, and (I don't think) external dependencies are involved*.

For most modules I've worked on, having npm manage dependencies, and being able to easily consume these is a huge advantage. As far as I can tell this approach doesn't work with UMD (again, please correct me if I'm wrong).

So I just don't see it as an approach I would want to use unless:

- Supporting all environments is critical
- The module doesn't have any external dependencies

I definitely lean in the direction – probably ignorantly – of just use CJS.

* I've only skimmed the Lodash source, I should take a closer look when I get the chance.