What This Error Means
npm rejected the package name because it does not follow npm naming rules, such as invalid characters, uppercase letters, or reserved names.
Read this as a precise clue about which part of the workflow broke first. Once you know the failing layer, the fix path gets much shorter.
How to Fix It
The fastest fixes here come from checking the immediate failing layer before you change anything unrelated. Make one correction at a time and re-test from the same environment.
Open package.json and inspect the name field first.
For unscoped packages, use a lowercase URL-safe name with no spaces (for example my-package).
For scoped packages, use @scope/package-name and keep both the scope and package segment lowercase.
If the package is not meant to be published, keep a valid name anyway so npm metadata validation passes.
Retry with npm pack --dry-run or the original npm command after fixing the name.
Why It Happens
Usually this comes down to the name field in package.json contains uppercase letters, spaces, or other non-URL-safe characters, an unscoped package name starts with a leading dot or underscore, or a scoped name is malformed and does not follow the @scope/package-name shape.
Verify the Fix
Print the current value with npm pkg get name, run node -p "require('./package.json').name" and confirm it matches the corrected value, and run npm pack --dry-run and confirm EINVALIDPACKAGENAME no longer appears.
Check the exact command and local inputs
Inspect package.json directly and confirm the name field is present.
If the package is scoped, confirm it contains exactly one slash after the scope, for example @acme/widget.
Check for uppercase letters or spaces before retrying the npm command.
Examples
Invalid package name: "MyPackage" # uppercase letters
Invalid package name: ".internal-tool" # leading dot without a scope
Valid package name: "my-package"
Valid scoped package name: "@acme/build-tools"How npm validates the command before it runs
npm validates package metadata locally before it needs to talk to the registry. Package names end up in URLs, CLI arguments, and local folder paths, so invalid names are rejected early. Because this validation happens first, registry availability and auth are usually unrelated to EINVALIDPACKAGENAME.
Prevent It From Coming Back
To prevent this, keep package names lowercase and URL-safe from the start, validate package.json changes in CI with npm pack --dry-run before publishing, and use a review checklist for scoped package names so the scope and package segments stay consistent.