Package name similarity detection needs improvement

[dsherret]

🏷️ Discussion Type

Bug

Body

The package name similarity detection lists completely unrelated names that would never typo.

I'm listing this package name as an example because it's one I don't want:

403 Forbidden - PUT https://registry.npmjs.org/sfr - Package name too
similar to existing packages st,swr,sax,shx,sirv,sift,ssri,bfj,tar,bser; try renaming
your package to '@dsherret/sfr' and publishing with 'npm publish --access=public'
instead

I've tried a bunch of package names and can't publish them.

Similar sentiment: https://x.com/_developit/status/2033015833660674190

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[favoyang]

Adding another concrete false positive and a related tooling request.

I tried to publish the unscoped npm package planrock for https://github.com/favoyang/planrock and npm rejected it with:

403 Forbidden - PUT https://registry.npmjs.org/planrock
Package name too similar to existing package la9rock; try renaming your package to `@favoyang/planrock` and publishing with `npm publish --access=public` instead

I contacted npm support, and they confirmed that when an unscoped name is blocked by the automated name-similarity safeguards, support cannot manually override or allowlist the unscoped name. I have published the fallback scoped package at https://www.npmjs.com/package/@favoyang/planrock, but the desired CLI UX is npx planrock.

Two improvements would make this much easier for legitimate package authors while preserving typosquatting protection:

1. Improve the similarity check to reduce obvious false positives like planrock vs la9rock, where the names differ in readable words, pronunciation, and project context.
2. Provide a public preflight endpoint or CLI command that runs the same npm name-similarity checks without requiring a real publish attempt. For example, npm name-check planrock or a registry API endpoint could return whether the name is available, blocked by similarity, and the blocking package names.

The current flow forces authors to discover this only at publish time, often after repository, documentation, package metadata, and release automation are already prepared.

[ArgusPano]

Yeah.

https://github.com/orgs/community/discussions/199372

[maheerCodes]

just chiming in since i left a comment on @ArgusPano's related discussion ,,
@favoyang that detail about support not being able to manually override is really important ,,,i had suggested opening a support ticket as a possible path in the newer thread but didnt know support had confirmedd they cant bypass it. thats a significant gap in the current system.
the two improvements you listed are exactly right :

• the similarity algorithm clearly needs context-awarenesss,,, planrock vs la9rock and geodot vs reodkt are both obvious false positives that no real user would confuse.pure string distance without any semantic or phonetic weighting is too blunt
• the preflight check idea is genuinely great,,forcing authors to discover this only at publish time after alll the repo setup and release automation is done is a really frustrating UX. even a simple npm name-check command would save a lot of wasted effort
  the scoped package workaround is fine for library use ,,,,, but for CLI tools where npx planrock is the intended UX , being forced into npx @favoyang/planrock is a real downgrade in usability. thats a meaningful distinction npm should weigh when evaluating these false positives,,,,,,,