Replies: 2 comments
|
💬 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 ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
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. ⭐ |
|
I agree that this is a valid developer-experience issue. Automated similarity checks are useful for preventing typosquatting, but they can also produce false positives when a package name is intentionally similar to a legitimate word or an established project. |
Uh oh!
There was an error while loading. Please reload this page.
🏷️ Discussion Type
Bug
Body
Words that may appear too similar algorithmically (i.e. "vicary" and "vary") are easily distinguished by a human and yet denied by the filter. This owing to the fact that "vicary" is a valid dictionary word and, based on keyboard layouts, "vicary" is a highly unlikely typo of "vary."
The net result is that a package like vicary (http://github.com/bwthomas/vicary) that is maintains parallel implementations in python, ruby, and JS, is published as pypi package 'vicary', ruby gem 'vicary' ... and as '@bwthomas/vicary'
At a minimum, npm support should have the ability to override the classifier. I would also suggest the classifier add rules that take into account dictionary words versus misspellings.
All reactions