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.
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.
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.
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.
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.
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.
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.
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.
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.
NPM used to have its own search, then one day in late 2016 decided to outsource it to https://npms.io/ . That may be directly related to the issue at hand
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.
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.
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.
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).
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.