Pacakge discoverablity

[faiq]

Hey y'all! I'm Faiq the intern at npm! I've been tasked with the task of improving search and I was wondering what you guys look at when discovering new modules.

Do you guys search for module by name? Functionality? Author?

And when you find a package do you look at: How well maintained it is? Stars? Who the author is?

Try to follow the following format when answering, so I can get a gauge of how important each thing is

What I search by: (Descending order of importance to me)

1. Functionality
2. Package Name
3. Package Author

How I figure out if a module is good:

1. If it has up to date dependencies
2. download count
3. maintenance

Tell me everything, but try not to make the lists too long!

[toddself]

Search by

1. functionality (keywords like: mail, stmp, gmail, etc)
2. package name (rarely try just a package name)
3. package author (only if I know the author has a package that I think does what I need)

How I choose:

1. maintenance vs version number. below 1.X should have more frequently updates.
2. look at package.json: does it have a main field? are dependencies listed with versions or just "" or "*"
3. are there tests? does travis or similar tell me the package is build correctly
4. are there are TON of issues/pull requests with no response from the maintainer?
5. look at dependencies -- are they up to date?

[buritica]

What I search by:

1. functionality

How I figure out if a module is good:

1. does it have tests? 2 Date of last commit

2. of open issues

[junosuarez]

@faiqyou I shared some comments with you at nodeconf, but I want to clarify the way I think about dates.

A lot of small modules in npm haven't had new versions issued in multiple years, but still work great. So, rather than just the last-published date of the module, often I'll look at the author's last active date (that is, when they last released a module, even if it's a different one).

As an example, I used a module, https://www.npmjs.org/package/git-fs , which hadn't been updated in over a year. But, I know that the author, @creationix, is very prolific and responsive. So I felt confident using the module. When I had an issue with it, I was able to interact with the author via Github and Twitter and get my issue resolved and a new version of the module published. (https://github.com/creationix/node-git/pull/14 and https://twitter.com/_jden/status/487507800273080322 )

What I'm trying to get a sense of when I look at a date is how response a maintainer is.

[aredridel]

I search by functionality and name often; I really want to search for "works well together with...", but the data doesn't exist. I search by author for only a few authors (raynos, rvagg, substack, tjholowaychuk, creationix)

To see if it's good? Up to date dependencies; no extraneous dependencies; dependencies for common things rather than inventing their own; If it covers the use case completely; whether it tries to invent its own dependency management system; whether it plays nice with the module system; whether it has dependencies larger than it is.

If it's non-trivial and has non-simple interfaces, I make sure there's a test suite that covers the interface I want to use. I look for hints that they follow semver, not blindly increment numbers.

And most of all, I look for signs that a project is 'done' -- implements current interfaces, has nothing outstanding, no obvious missing feature, no extraneous features that will drive updates.

[aredridel]

Interestingly, @toddself, I look for updates past 1.0. In a semver world, I think hitting 1.0 early is very smart.

[nizaroni]

Hi Faiq!

What I search by:

1. Functionality keywords (recent example: "remove emoji")

How I figure out if a module is good:

1. Good README (explains what it is and how to use it)
2. Has the API I desire (or an approximation thereof)
3. Date updated on npm if there are a lot different options
4. Sometimes I use the author as a tiebreaker if somebody like substack happens to have written one of the candidates

[devfacet]

What I search by:

1. Functionality
2. Package name

How I figure out if a module is good:

1. Tests
2. Commit or release frequency
3. Last update
4. Dependents
5. Dependencies (Less is better)
6. Number of contributors
7. Package author

P.S. : "If it has up to date dependencies" doesn't matter in some cases.

[talon]

What I search by: functionality best on high level subject (example: http, irc, map, streams) author

How I determine if it is good: Documentation Source Code

[chrisdickinson]

What I search by:

1. Package name (often as a guess -- "If I wrote this package, I would name it X. Better go to npm.im/X" -- this works surprisingly well!)
2. Keyword-as-tag-for-ecosystem ("level", "voxel")
3. Keyword functionality

How I determine if it is good:

1. must have repo link. If there's no repo link, it's very unlikely that I'll use the package.
2. must have license. License must be permissive.
3. must have a readme that answers the following quickly: does it look like it does what I want? Easiest to determine when "example" code is above the fold, in the order "module name, 1-2 sentence synopsis, example code".
4. Download count -- is this module actively used, even indirectly?
5. Repo/code details -- is it compile-to-js (if so, instant negative marks). Is it small? How many package description + build files are there? I have a little bit of a negative reaction towards seeing Cakefiles, Gruntfiles, gulpfiles, bower.json, component.json all at the top level. Are there tests? How many issues are there? Does it have a license file?
6. Dependents -- by both download count + author, i.e., "I trust <author/packages>'s taste in modules, and they directly or indirectly use this module."
7. Is it single export? I prefer single-export to grab-bag modules, generally.

(In short, there are a few must-haves, which gets narrowed down to "community signaling")

[mzabriskie]

I search by:

1. Keywords
2. Package name

I judge by:

1. Downloads
2. Last updated

[parshap]

What I search by:

1. Functionality. This is the only hard constraint when I'm looking for a package. I have a use case in mind and I am looking for something that meets my requirement. Package name and keywords are the ways in which I go about looking for the functionality. It's a pain because people like to be clever with their names and keyword search is not good (the UI is not good, keywords aren't curated well).

How I figure out if a module is good:

1. Documentation: I'll look at the readme to get an idea of how to use the package and the scope. I usually some preferred semantics in mind and if the package derails from that too much then I'll look for one that doesn't (e.g., I want to search Flickr for photos by subject, this packages only search by username). I also try to understand the scope of the package to make sure it doesn't do too much more than what I'm looking for (e.g., I want to search photos on Flickr, this packages aggregates photos from multiple different services).
2. Source. I'll skim a package's source to get an idea of the implementation and make sure nothing crazy is going on.
3. Author: If I'm familiar with the author and share the same philosophies then I can usually spend less time looking at the other things on this list.
4. GitHub Issues & Activity: I'll inspect the history of a project and see what issues have been discovered and how they've been handled. A lot of issues and no activity can show that there are problems with the package and the maintainer doesn't care. No issues (including closed ones) can show that the packages hasn't gotten much real use.
5. GiitHub Stars: Stars aren't too important, but if a project has a lot of stars it can show that the community has discovered the project and has found some value in it. Stars are often a tie-break between similar projects to decide which one I will try first.
6. Dependencies: If it seems like the problem the package is trying to solve would also depend on solving some other non-trivial problems, I'll look to see if the package uses an external dependency to solve those other problems. E.g., I would expect that a package that searches Flickr for photos by subject would depend on a package that can retrieve photos from Flickr and a package that can identify the subject of a photo (this analogy isn't great, but hopefully it demonstrates the idea). If the package doesn't do this, it's not necessarily a bad thing, but I'll look at the implementation to understand why.

[ruimarinho]

What I search by:

1. Functionality / keywords: I usually type one or two keywords but I always have a feeling that npm has trouble mixing them together.

How I figure out if a module is good:

1. Activity metrics (in descending order)
   • Github / NPM stars: stars are far from a reliable relation to code quality, but they suggest the community has found value in the package and in a way validates its results since it is most likely to have fulfilled the most common set of requirements. Sometimes it's more important to rely on a battle-tested not-so-good-looking code then pristine but untested code.
   • NPM download count: another metric that indicates if a package is widely used or not.
2. Package author: certain prolific community members are known to publish very high-quality modules with most of the good characteristics I personally look for and describe in this comment. Consistency is key.
3. Maintenance: good packages are well-maintained and usually have an update in the scope of months. I usually avoid packages with more than 10 months of inactivity unless their feature set is very well defined (e.g. traverse) or the package has clearly reached a plateau due to its maturity.
4. Documentation: a well-written README shows that the author has spent time thinking about how the API should look and feel and also indicates a great deal of care to publish something that is easily understood by others.
5. Metadata:
   • Repository: a package without a repository usually means the author is not willing to accept suggestions or code contributions.
   • Scripts: I like to see the author's methodology to run tests during development by taking a look at the scripts used. It usually gives me an insight on the programmer's experience.
6. Dependencies: authors of high quality modules usually choose their dependencies wisely, i.e., they similarly look for other high quality modules to depend on, which is a reflection of their own experience and time spent in research.
7. Tests: I can't remember the last time I've seen a package without tests so I was reticent about even considering this as a way to figure out if a module is good. I think that, in general, the community at large has adopted this software development methodology and bad tests can also offer a false sense of security.

In general, I take a quick look for a small number of metrics that allow me get an overall feeling on the quality of the module. If it looks promising, then I jump to the other non-analytical data that is what you can't currently get from npm's search engine. I'd love to see that change :)

[ascott1]

What I search by:

1. Functionality. This is what I'm search for more than what I actually search by. I typically type in a few keywords and then sift through the results.

How I figure out if a module is good:

1. Clear README/Documentation with example usage
2. Github issues and activity that show the package is being actively maintained (though to @jden's point, this isn't always a great indicator)
3. Source code after checking out the Github activity, I usually take a look at the source code. This can vary from a deep dive into the code to a quick skim to make sure it follows best practices.