
Dawn of the Dead NPM Packages - rnosov
https://www.react-reveal.com/blog/npm/
======
treve
I also noticed the search is pretty awful. I published a library that was
impossible to find (even if written in full) because hitting 'enter' after a
search just went to a more popular library that must have a closely matching
term somewhere in their keywords or description.

So my only option for making the library findable at all, was to use a word
that was unlikely to appear in any other fields of other packages. I settled
on a dutch translation of one of the concepts used in the package, that would
still have a predictable spelling if an English speaker heard it.

It's unfortunate, because the implication is that if you want your package to
be found at all (assuming you already know the full name of the package, not
even talking about discoverability), you need to pick a name that's unlikely
to have any bearing on the function of the package.

------
dguo
Last year, I switched to using the Yarn website[1] to search for packages.
It's powered by Algolia[2], and it delivers much better results in my
experience.

[1]: [https://yarnpkg.com](https://yarnpkg.com)

[2]: [https://discourse.algolia.com/t/2016-algolia-community-
gift-...](https://discourse.algolia.com/t/2016-algolia-community-gift-yarn-
package-search/319)

------
franciscop
I am a dev who uses Node.js a lot and published quite a few packages; the
state of npm is very, very sad. It has evolved from being one of the great
things on Node.js to something you have to fight constantly with
counterintuitive defaults everywhere. Not that it used to be much better, but
these issues were only acceptable when the ecosystem was smaller.

------
RyJones
I’ve had a lot of difficulty dealing with NPM as a customer. Changing a
billing date is not possible, and you cannot get annual plans that are
reasonably priced. As it is, I expense $14 a month in NPM expenses every month
with no ability to switch to an annual billing.

The request to change a billing date was met with a hilarious response. Pause
using the paid plan until you get to the day where you want billing to start,
then unpause. In the interim, access to the paid features would be gone.
Thanks, but no!

GitHub, by way of comparison, was a dream. Change the billing date to the
first? Done and done.

------
shp0ngle
Ahhh, the wonderful world of npm, where every small task has 20 libraries that
are all named the same and half of them are abandoned and the other half have
confusingly overlapping feature sets, and sometimes are actually all from the
same authors.

~~~
sumoboy
I thought wordpress plugins were bad keeping up to date, NPM is the same
nightmare. Better filtering needed.

------
sbr464
I agree with the author 100%. I personally never use npm directly for search.
I also prefer to just use google as a start, and usually find the github
results there more appealing. I realize it’s not npm’s prerogative to satisfy
what I like, but I don’t really understand their motivations either. A basic
account costs $5-15/month for what I feel is a critical ecosystem service as
the author puts it. It feels like the quality of the UI is related to this
cheaper price, when I for one would pay much more for a better experience. It
feels like they are selling themselves short for the importance they have
achieved. It kind of feels like either the original product managers lost
motivation, or they’ve become too big to have people that really care. (Or
have to say this, they are just stuck up hardcore devs that don’t care about
the real world) I’m definitely not ranting and appreciate npm, but wanted to
write my feedback here in case it’s read by them.

------
royjacobs
It's a shame that npm seems to have such a hard time doing what's it's
supposed to do: making packages easy to discover, use and keep using.

------
tlrobinson
FWIW I usually use [https://npmcompare.com/](https://npmcompare.com/) to find
packages that are actively maintained

~~~
franciscop
Doesn't work on mobile

~~~
tlrobinson
Fortunately I (and probably most people) don’t usually program on their mobile
devices...

~~~
franciscop
Ah didn't think that one, just wanted to quickly test it. But I do use my
phone on dead times (like train) and some times check npm there to see if my
idea exists and for possible names. Guess not such a big case for USA where
you mostly drive everywhere though.

------
iamleppert
It’s really sad that npm has a great platform and amazing opportunity to
innovate and deliver a great developer UX. I was going to apply there and see
if I could get an interview to figure out what’s up with them, and maybe to
try and take things in a better direction.

------
CaliforniaKarl
I’m guessing that the problem is the search engine? It would be interesting to
compare the search/suggestion engines of CPAN/PyPI/rubygems/npm/CRAN, because
this can’t be a problem that has only been faced by npm.

~~~
tyingq
Part of it is scale and growth rate. CPAN has around 36k packages but it's
been around decades. NPM exceeded 350k a while ago.

See [http://www.modulecounts.com](http://www.modulecounts.com)

~~~
TAForObvReasons
NPM used to have its own search, then one day in late 2016 decided to
outsource it to [https://npms.io/](https://npms.io/) . That may be directly
related to the issue at hand

~~~
SenHeng
Using the search terms used in TFA, npms.io seems to return the expected
results compared to whatever's used on npmjs.com. So I don't think we should
blame them.

------
deathtrader666
The Elm package library is such a breath of fresh air! I'm glad I moved over.

------
tomc1985
This is a really harsh assessment of a crappy search engine.

~~~
sbr464
I honestly wouldn’t refer to them as a search (engine). Implementing a keyword
search with a Lodash function and a few if/else rules feels like it would
provide better or comparable results to the current offering. I wouldn’t refer
to that as an engine.

------
z3t4
most of the code we run every day is very old. the idea with open source
packages is that you do not have to repeat the work made by others. but you
can improve it if you can/want. old code is often "battle tested" and thus it
can actually be safer then something that get constant updates.

~~~
cyphar
That's not related to the issue at hand, which is that users searching for
_actively maintained_ projects are getting sent to _old unmaintained_ projects
that are abandoned for reasons other than "it is so stable it needs no
updates". It's like trying to install CUPS (last updated a month ago) but
being redirected to cup-stacker-pro (last updated in 1997). Sure, it's
definitely old code, but is it really a good idea to install it?

But I also disagree that old _code_ is "battle tested". Old _codebases_ and
old _projects_ are a different story. Running a binary built 10 years ago
isn't generally a good idea, but running a modern release of a 10-year-old
project is almost always better than a project started 2 weeks ago. The
benefit of old _codebases_ is the experience of the maintainers involved, but
you don't get that benefit if the codebase hasn't been maintained (or you're
using a release that was made before they gained that experience).

