Open faiq opened 10 years ago
Search by
How I choose:
package.json
: does it have a main
field? are dependencies listed with versions or just ""
or "*"
What I search by:
How I figure out if a module is good:
@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.
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.
Interestingly, @toddself, I look for updates past 1.0. In a semver world, I think hitting 1.0 early is very smart.
Hi Faiq!
What I search by:
How I figure out if a module is good:
P.S. : "If it has up to date dependencies" doesn't matter in some cases.
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
What I search by:
npm.im/X
" -- this works surprisingly well!)How I determine if it is good:
(In short, there are a few must-haves, which gets narrowed down to "community signaling")
I search by:
I judge by:
What I search by:
How I figure out if a module is good:
What I search by:
How I figure out if a module is good:
traverse
) or the package has clearly reached a plateau due to its maturity.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 :)
What I search by:
How I figure out if a module is good:
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)
How I figure out if a module is good:
Tell me everything, but try not to make the lists too long!