DEV Community: Antonio Stoilkov

Better npm search proposal

Antonio Stoilkov — Tue, 19 Jul 2022 13:59:51 +0000

TL;DR; Current npm search engines aren't great. I explore a npm search algorithm that gives fewer points for popularity and more for consistency of commits, releases, and responses in issues/discussions. This way I want to: 1) save a lot of developer time, 2) give visibility to conscientious developers who don't promote their work, 3) and more 👇.

The problem with finding a good npm package

I have constant issues with finding good npm packages:

npms.io is the best-performing algorithm for me. However, sometimes it's slow, other times I get an error and no results. Some checks no longer work — this results in older packages having higher scores because the index is updated only when a new version is published. If you go through the implementation, you will find a lot of the ranking is determined by some things that don't correlate well with how good the library is ¹. All this reminds me of Bogus rankings damage what they rank. Especially if those being ranked play along.

npmjs.com search is bad. For example, one of my libraries that shows at the top on npms.io shows in 13th place on npmjs.com. The library is the most downloaded localStorage hook and I had consistent commits and releases for the past 2 years. I don't know what happened with npm Blog Archive: Better search is here!

Others. I have hopes for the future of socket.dev — it often has good results. However, the UX still has some issues and sometimes the results aren't optimal. libraries.io search quality is sporadic. I also use GitHub search and Google.

Currently, I use the bash script below to search, the places I mentioned, all at once:

args=$@
encodedValue=$(node --eval "process.stdout.write(encodeURIComponent(\"$args\"))")

open -a "Google Chrome" \
  "https://npms.io/search?q=$encodedValue" \
  "https://socket.dev/search?q=$encodedValue" \
  "https://github.com/search?l=TypeScript&q=$encodedValue&type=Repositories" \
  "https://github.com/search?l=JavaScript&q=$encodedValue&type=Repositories" \
  "https://libraries.io/search?languages=&platforms=NPM&q=$encodedValue" \
  "https://www.google.com/search?q=site:npmjs.org+$encodedValue"

The bash script helps. However, this workflow is time-consuming and frustrating. My experience is: I open 10-20 tabs, close duplicates, close all irrelevant, close all without any activity, dive deep in those that are left. It seems a lot of other people have my problem.

My proposed solution

The main question I ask myself when I think about a solution is: If you open-source the algorithm and people try to optimize for it, does it yield better libraries? Here are the things I'm proposing:

Commit, release, response consistency. Most points are given for consistency of releases, commits, and issue responses (excluding non-maintainers). The longer the period of consistency, the better — libraries that have existed for a lot of time and have been consistently updated should have the highest scores. Think about it, if a library has been consistently updated for a lot of time, don't you want to see it regardless of the download count? More points for evenly spread activity, fewer points for occasional bursts ². Optionally, if a library is over a threshold, show an icon/badge for consistency.

Account consistency. Some people go directly to Sindre Sorhus's repositories page and search there. If a person spends a big amount of time contributing, that's valuable. Give points to consistent accounts. Optionally, if a user is over a threshold, show an icon/badge.

Popularity. You can't ignore stars and downloads. That's an important factor. However, give it fewer points. This is a key aspect of this algorithm.

Give more points to. Most search engines have a "Sort by" option. This doesn't work. This is why I'm proposing an alternative "Give more points to" option that just switches the magnitude for specific criteria. Possible values will be "Repo consistency", "Account consistency" and "Popularity". "Repo consistency" will be selected by default. Selecting "Popularity" will make it work more like existing search engines.

Exclude bots. Bots activity should be excluded, otherwise, the search will probably get a lot worse. Also, it opens an opportunity for easy manipulation. For example, a version bump by a bot shouldn't count at all. Similar to how GitHub's repo contributions page work.

A possible pitfall in the idea

A big portion of repos will have a low consistency rating. A good fallback may be needed to account for that. I'm not sure if popularity is good enough of a fallback.

Is it possible the strange and opinionated scores used by other search engines needed? — I would bet on "no" but I'm very cautious with that guess.

What I've done to move the idea forward

I contacted Algolia and they gave me access to their npm index. I can use it for a basic implementation of my idea because it includes the history of all the releases. Also, the API returns sorted search results that can be used as a fallback or a base score. Not sure if this will be enough to produce consistently better results compared to other search engines.

I created a new discussion in the npm/feedback repo to share my idea. I also mentioned my idea in relevant discussions: npm scores, Weird search behavior with stats, and Improve search functionality on npmjs.com.

If you are a person that can move this idea forward, please write to me.

Why I wrote this article

At first, I wanted a better search. However, after researching and exploring the topic I now like it more for the opportunity it can create:

save a lot of developer time ³
allow non-vocal but conscientious developers be recognized
when incentivizing the right thing, in theory, the quality of libraries and the ecosystem as a whole should improve
in a utopian future, when the ecosystem improves and more rely on open-source, open-source developers get paid better

Some of the considered things for the ranking are: badges count in the readme, readme length, .npmignore or package.json's files property, existence of changelog.md file, does it use a linter. Some of the checks aren't implemented well and incorrectly return false. npms.io ranking algorithm explained ↩
I'm not entirely sure what the specific implementation should look like. I think it should calculate evenness. Something like this — Is there a measure of 'evenness' of spread?. However, if you understand the algorithm/maths behind it, write to me so I can add it to the article. ↩
Reminds me of a Steve Jobs story — Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day.. ↩

My open-source principles

Antonio Stoilkov — Thu, 14 Jul 2022 11:52:56 +0000

Open-source is amazing but you can't fully rely on it. Repos are abounded, removed, introduce vulnerabilities, become bloated over time, and won't make the fix you need. My goal is to avoid this.

I wish that other developers may see this, like some of my principles, and apply them to their work.

Principles

My strategy against project abandonment. I don't open-source often because it's hard to determine the things that you won't abandon. I've made that mistake before and I believe it's destroying more value than it's creating. I test if a repo is worth open-sourcing by privately using it for 6 to 12 months. If I continue using it, I put it in a list of candidates. I have over 150 local modules waiting and around 20 in the list of candidates.

Activity. Most of my responses are within 24 hours. I hate stale bots. I am conscientious enough to keep track of my issues. I am quite consistent at working on my libraries. Here are more than 2 years of contributions for use-local-storage-state.

Helping you choose. npm search engines aren't great. Finding the right library isn't trivial. I often struggle with this. That's why, at the end of each readme, I will list repos that, support something my library doesn't, have some advantage over it, or have a smaller bundle size. The only requirement is that they are actively maintained. I will remove any library that becomes stale. If there is a repo that's better than mine, I will put it on top of the readme.

Reliable. I do a few things to ensure that the library is reliable and works well:

100% test coverage.
My super strict ESLint rules — eslint-config-strictest.
If there is a bug, when fixing it, I also create a test for it.
Every repo I open-source is used in my own products. Either Nota or iBar.
TypeScript with all strict options enabled (including noUncheckedIndexedAccess).

No bloat. I am inspired by Sindre Sorhus. I aim to create small and focused modules. I commonly decline feature requests and propose an alternative ad-hoc solution to the user. When the request is valid and can't be implemented outside the library, I usually refactor enough so the bundle size remains almost the same. Take a look at the history of use-local-storage-state through the last versions. The size got smaller! If the feature is too big, I may consider splitting the problems into two repos.

Learn from the code. I commonly read and learn from the code of other libraries. That's why I decided to write a lot of comments — example. This way you can learn more about the domain and implement a custom solution if you need it.

Open-source contributors worth sponsoring

Antonio Stoilkov — Thu, 30 Jun 2022 07:55:58 +0000

Open-source creators are underpaid. Their passion for OOS makes businesses rich. This isn't an equal distribution. ¹

GitHub Sponsors made it easier to monetize your open-source work. Being willing to give your money to support an open-source creator is rare — let's not make it harder. This is why I decided to create this list.

Titus — @wooorm
- 25 sponsors.
- Titus has created an entire ecosystem of libraries around text processing. I have used many of his repos. Markdown, MDX, NLP, HTML, language section.
- I feel like he doesn't promote himself enough.
Kyle Simpson — @getify
- 10 sponsors.
- The hugely popular book You Don't Know JS with 140k stars (the 7th most starred repo on GitHub).
- Personally, I am astonished how Kyle Simpson may have only 9 sponsors. It feels like he has done so much for the community to get better at JavaScript.
- Note that it is unknown how much he makes by selling his books. It is possible he successfully monetizes his content.
Feross Aboukhadijeh — @feross
- 42 sponsors.
- He also searches for ways for open-source creators to monetize their work so they are more motivated. He created thanks and funding.
- He makes amazing stuff. I have tried Standard, used WebTorrent Desktop. He also recently launched Wormhole - Simple, private file sharing.
Fabio Spampinato — @fabiospampinato
- 31 sponsors.
- If you are a VSCode user, you definitely should consider him. He made more than 30+ VSCode extensions. When I was using VSCode, I have unnoticeable been using his extensions.
- In the sponsor page he writes "This would allow me to pay rent each month without eating up my savings, and lower the stress level considerably.". These are the people who need help the most.
Sarah Drasner — @sdras
- 52 sponsors.
- Awesome creator with multiple popular repositories that create a lot of value.
- If you use Vue — she is a maintainer of their documentation.
TJ Holowaychuk — @tj
- 27 sponsors.
- The creator of Express.js, Koa, Mocha, Commander, Apex, Up, ReworkCSS, PostCSS. I feel like he has created so much value for the community.
- He has 39 sponsors but with only one tire of $400 per month. He may had smaller tiers in the past. However, if he has 39 sponsors paying $400 per month this means he makes a lot.
Nicholas C. Zakas — @nzakas
- 77 sponsors.
- The creator of ESLint. The writer of Understanding ECMAScript 6. The cool Computer Science in JavaScript and many more. Note that ESLint is sponsored separately — https://github.com/sponsors/eslint.
- > In 2016, I had to give up all full-time and part-time work as I became very ill with Lyme disease. I've been working my way back to health ever since and truly hope I'll be back to full strength sometime during 2020. In the meantime, I contribute to various projects as my health allows, so it's not uncommon to see bursts of activity followed by time where I'm not active.

If you want to sponsor the people you depend on, you can:

Go to https://github.com/sponsors/community and see all repos you depend on that also have a sponsor option.
Run npx thanks in the root of your repository and see who to sponsor based on your repo and not your entire user or organization — thanks.

This list isn't complete as I probably don't know a lot of worthy people. If you have a suggestion, please write to me at hello@astoilkov.com so I can add them.

You can also see Monetizing open-source is problematic if you are interested in the topic of funding your open-source work. ↩