One of the most common objections I've heard about embracing modularity andfavoring librariesthat do a single thing wellis that it can be difficult and time-consuming to find packages for each pieceof functionality you might need for a given task.

This is certainly true at first, but over time and with practice, it is less andless of a problem as you train up your own heuristics and develop a broadworking memory of useful packages and authors who tend to produce useful codethat suits your own aesthetic preference.

With a bit of training and practice, you will be skimming npm search results atgreat speed in no time!

my heuristic

Here's my own internal heuristic for evaluating npm packages:

• I can install it with npm

• code snippet on the readme using require() - from a quick glance I should seehow to integrate the library into what I'm presently working on

• has a very clear, narrow idea about scope and purpose

• knows when to delegate to other libraries - doesn't try to do too many things itself

• written or maintained by authors whose opinions about software scope,modularity, and interfaces I generally agree with (often a faster shortcutthan reading the code/docs very closely)

• inspecting which modules depend on the library I'm evaluating - this is bakedinto the package page for modules published to npm

When a project tries to do too many things, parts of it will invariably becomeneglected as the maintenance burden is unsustainable. The more things a projecttries to do, the easier it is to be completely wrong about some assumption andthis can also lead to abandonment because it's very difficult to revisitassumptions later.

The best, longest-lasting libraries are small pieces of code that are verytricky to write, but can be easily verified. Highly mathematical tend to be verywell represented in this category, like thegamma function or an ecosystem of highlydecoupled matrix manipulation modules such asndarray.

When a library is embedded in an ecosystem of other libraries in a thoroughlydecoupled way, a mutual dynamic results where the main library doesn't need toinflate its scope but gets enough attention to find subtle bugs while thedependent libraries can offer excellent interoperability and fit into a largerinformal organizational structure.

not too important

Here are some things that aren't very important:

• number of stars/forks - often this is a reverse signal because projects withoverly-broad scope tend to get much more attention, but also tend to flame outand become abandoned later because they take too much effort to maintain overa long period of time. However! Some libraries are genuinely mistakes but ittook writing the library to figure that out.

• activity - at a certain point, some libraries are finished and will work aslong as the ecosystem around them continues to function. Other libraries dorequire constant upkeep because they attack a moving problem but it's importantto recognize which category of module you're dealing with when judgingstaleness.

• a slick web page - this is very often (but not always) a sign of a librarythat put all of its time into slick marketing but has overly-broad scope. It issometimes the case that solid modules also have good web pages but don't betricked by a fancy web page where a solid readme on github would do just as goodfor a job.

The main crux of this blog post first appeared as areddit comment.