A common question: why would anyone publish a single-function module?
It might seem odd to have a module with just a single function (examples: clamp, is-dom, is-url, object-assign, point-in-polygon). Sometimes your tests and documentation are longer than the function itself. Let's examine some of the benefits to this approach...
- a terse and frozen API does not end up with the scope creep or code rot that larger frameworks and "standard libraries" tend to carry.
- it encourages diversity rather than "this is the one true way" (e.g. robust-point-in-polygon handles edge cases at some cost to performance/filesize/etc).
- it generally leads to less fragmentation overall, e.g. many modules begin to depend on the same request animation frame and xtend functions rather than constantly reinventing the wheel or copy-pasting from a Gist (without upstream patches/bugfixes).
- less fragmentation means tighter applications and reduced duplication and filesize in the case of front-end bundles.
- each function is versioned, documented, tested, and used in isolation. A version change to camel-case does not affect title-case. The docs of one module are not muddled with the docs of another.
- it is better for building re-usable code. You aren't bringing in the bloat, versioning woes, scope creep, and opinions of a larger framework. Writing application code that depends on "tiny modules" is trivial to modularize and then further build on and reuse.
Should you start writing "tiny modules" instead of big kitchen sink frameworks? That's up to you. There are pros and cons to both approaches.
I've personally come to favour small and isolated modules; they've increased my productivity and the sustainability/reusability of the code I write.
Also see: Sindre's Answer to one-line node modules