Package name follows conventions
Why it matters
Package names on npm are permanent. Publishing MyUtils or helpers creates a name that cannot be renamed without breaking every downstream install. CamelCase and underscores in package names violate npm naming rules and can trigger resolution issues in some bundlers. Generic unscoped names (utils, lib, tools) are either already taken or so ambiguous that consumers cannot distinguish your package from dozens of identically named ones. A scoped name (@yourorg/my-utils) is the only way to guarantee namespace ownership.
Severity rationale
High because package names are immutable post-publish — a non-compliant or generic name cannot be corrected without abandoning the published identifier and re-publishing under a new name.
Remediation
Rename the package to lowercase kebab-case and use an npm scope to guarantee uniqueness.
{
"name": "@yourorg/my-utils"
}
Create an npm organization at npmjs.com/org/create if you don't have one. After renaming, deprecate the old name with npm deprecate myOldName 'Moved to @yourorg/my-utils'. Any package.json files referencing the old name in consumer projects will need updates — communicate the migration in a major version bump.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the SDK / Package Quality Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · maintainability.modifiability — Modifiability — consistent naming reduces consumer confusion
Taxons
History
- 2026-04-18·v1.0.0·Initial import from sdk-package-quality·automated