Package name 'shapit' rejected as too similar to 'hapi' - no way to detect before publishing ?

[AssilemSDN]

🏷️ Discussion Type

Bug

Body

Hi,

I'm the maintainer of Shapit, an open-source CLI for auditing projects against configurable rules.

I've recently prepared the first release (v0.1.0), but when attempting to publish the package to npm, I received an E403 error stating that the name shapit is too similar to the existing package hapi.

I understand the importance of preventing typosquatting, but I believe this may be a false positive.

Shapit is an independent project with a completely different purpose from Hapi, which is a Node.js web framework. The name comes from the idea of shaping project standards, and there is no intention to imitate or create confusion with Hapi.

The main issue

What I find particularly frustrating is that I couldn't find a way to detect this restriction beforehand.

The package name appeared to be available, and npm pack --dry-run completed successfully. I only discovered the restriction during the actual publication attempt, after preparing the documentation, CI workflows, and GitHub release.

For developers publishing their first package, discovering a naming restriction this late in the process is quite discouraging.

I also noticed that a similar concern has already been raised in npm/cli#9188.

Questions

1. Is there an official process to request a manual review of this restriction? I'd really like to keep the unscoped name shapit.
2. Is there a way to check package name similarity restrictions before attempting publication?
3. Could this validation be exposed earlier, or at least provide a clearer way for developers to check whether their chosen name is acceptable?

I understand why these protections exist, and I'm not suggesting they should be removed. I just think the validation process could be more transparent and developer-friendly.

Thanks for your time!

[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. ⭐

[DYNOSuprovo]

1. Is there an official process to request a manual review?

Yes. You can appeal the automated typosquatting block by opening a support ticket directly with the npm team:

• Go to GitHub / npm Support or email support@npmjs.com.
• Select npm → Package publishing / naming issue.
• Provide your package name (shapit), link your GitHub repository, explain the distinct use case (code auditing CLI vs. the Hapi web framework), and request a whitelist override.

Honest expectation: While npm staff can grant manual exemptions, their policy on unscoped single-word names that fuzzy-match critical Tier-1 ecosystem packages (like hapi) is strictly conservative. Overrides are typically only granted if you own a registered trademark for the name.

---

2. The Recommended Solution: Publish as a Scoped Package (@assilemsdn/shapit)

The fastest and most reliable path forward—without changing your project identity or your CLI executable name—is to use an npm Scope:

1. Why this bypasses the restriction: npm’s typosquatting heuristic does not restrict scoped packages. Because your username or organization provides namespace isolation, @assilemsdn/shapit has zero naming conflict with unscoped hapi.
2. Keep the exact shapit CLI command:
   Users will still run your tool as shapit. Your package.json can retain the exact binary alias:

   {
     "name": "@assilemsdn/shapit",
     "version": "0.1.0",
     "bin": {
       "shapit": "./bin/cli.js"
     }
   }

   When installed globally (npm install -g @assilemsdn/shapit) or run via npx (npx @assilemsdn/shapit), the user types shapit.
3. Publishing command: Scoped packages default to private, so remember to publish with the public flag:

   npm publish --access public

---

3. Why couldn't this be detected earlier (and how to check beforehand)?

• Why npm pack --dry-run didn't catch it: npm pack is an entirely offline client-side validation tool. It only verifies package.json syntax, file bundling, and size limits using validate-npm-package-name. It does not query the npm registry backend.
• Why npm doesn't expose the similarity check API: The typosquatting heuristic is implemented as a server-side validation function inside npm's CouchDB registry pipeline. It measures Damerau–Levenshtein distance, phonetic similarity, and token stripping against the top 10,000 downloaded packages. npm deliberately does not expose a public API endpoint for this check to prevent malicious actors from automating dictionary scans to find evasive typosquatting variations.
• Pre-publish checks you can use:
  While the official server-side similarity algorithm isn't in the CLI, you can inspect potential conflicts before committing to documentation by checking the registry endpoint:

  curl -s https://registry.npmjs.org/shapit

  If this returns 404, you can run a dry-run publish against a test registry or check community packages like npm-name or typoguard which simulate npm's string distance heuristics against top packages.

---

If this clarifies why the filter triggered and helps you publish under your scope, please consider marking this response as the accepted answer! 🚀