-
-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect squatters #5
Comments
Yes, that would be super useful! Should probably be opt-in as I assume it adds some overhead. Would you be interested in doing a pull request integrating it? One clear sign I've seen with squatters is that they usually have a readme, and sometimes an |
Great! Yeah, I am up for that. The README detection is already in place. I'm not currently doing any kind of code analysis, happy to say that hasn't seemed necessary so far. The overhead is a few hundred milliseconds. The vast majority of that is two API calls, one for the package metadata and one for the download counts. Currently run in serial so I can short-circuit where possible - could also experiment with concurrent requests and figure out if that helps the common case. Once the metadata is fetched, the heuristic is very quick. |
I find myself using the npm website a lot instead of this CLI. And when I thought about why, I realized it is because squatting is a common problem that is not taken into account here. Often a name is not technically available but only because someone is squatting on the namespace. On the website, I can see whether it is worth trying to acquire the name, but on the command line I have no way of knowing.
What do you think about incorporating something that would offer that kind of feedback into
npm-name
?My thinking is that it should still exit non-zero but display a warning instead of an error:
⚠ foo is squatted
I wanted to explore how that would work, so I built a squatting detector. Hope it is useful either way.
The text was updated successfully, but these errors were encountered: