Is there an existing issue for this?
I searched and found two prior reports that describe the same symptom, both now closed:
Re-filing because the behavior is still present on current npm versions and neither prior issue was actually triaged to a fix.
This issue exists in the latest npm version
Reproduced on npm 10.9.4 (node 22.22.0) and on npm 12.0.1 (run via npx).
Current Behavior
npm deprecate returns code E422 / 422 Unprocessable Entity - PUT https://registry.npmjs.org/<pkg> and exits non-zero, but the registry actually applies the deprecation write. Reading the packument back afterward shows the deprecated field correctly set on every targeted version. So the command reports failure for an operation that in fact succeeded.
This happens with both the range form and the single-version form of the command.
Verbatim error output:
npm error code E422
npm error 422 Unprocessable Entity - PUT https://registry.npmjs.org/<pkg>
The debug log shows the usual read-modify-write flow: a GET .../<pkg>?write=true returns 200, then the PUT .../<pkg> returns 422. Despite the 422 on the PUT, the deprecation is persisted (confirmed by a subsequent packument read).
Expected Behavior
When the registry applies the deprecation, npm deprecate should exit 0 and report success. If the PUT genuinely fails, the deprecation should not be persisted. The current state (client reports 422 failure, registry persists the write) is inconsistent and misleads automation that checks the exit code.
Steps To Reproduce
Using any package the reporter owns:
- Deprecate a range of versions:
npm deprecate "<pkg>@<=X.Y.Z" "<notice text>"
Observe code E422 / 422 Unprocessable Entity - PUT https://registry.npmjs.org/<pkg> and a non-zero exit.
- Deprecate a single version:
npm deprecate <pkg>@X.Y.Z "<notice text>"
Same E422 result.
- Read the packument back (
npm view <pkg> versions --json / fetch https://registry.npmjs.org/<pkg>) and confirm the deprecated field is set on every targeted version despite the reported error.
Reproduced across two npm/node combinations:
- npm 10.9.4, node 22.22.0
- npm 12.0.1 (via npx)
Environment
- npm: 10.9.4 and 12.0.1
- Node: 22.22.0
- Registry: registry.npmjs.org
Is there an existing issue for this?
I searched and found two prior reports that describe the same symptom, both now closed:
Re-filing because the behavior is still present on current npm versions and neither prior issue was actually triaged to a fix.
This issue exists in the latest npm version
Reproduced on npm 10.9.4 (node 22.22.0) and on npm 12.0.1 (run via npx).
Current Behavior
npm deprecatereturnscode E422/422 Unprocessable Entity - PUT https://registry.npmjs.org/<pkg>and exits non-zero, but the registry actually applies the deprecation write. Reading the packument back afterward shows thedeprecatedfield correctly set on every targeted version. So the command reports failure for an operation that in fact succeeded.This happens with both the range form and the single-version form of the command.
Verbatim error output:
The debug log shows the usual read-modify-write flow: a
GET .../<pkg>?write=truereturns 200, then thePUT .../<pkg>returns 422. Despite the 422 on the PUT, the deprecation is persisted (confirmed by a subsequent packument read).Expected Behavior
When the registry applies the deprecation,
npm deprecateshould exit 0 and report success. If the PUT genuinely fails, the deprecation should not be persisted. The current state (client reports 422 failure, registry persists the write) is inconsistent and misleads automation that checks the exit code.Steps To Reproduce
Using any package the reporter owns:
code E422/422 Unprocessable Entity - PUT https://registry.npmjs.org/<pkg>and a non-zero exit.E422result.npm view <pkg> versions --json/ fetchhttps://registry.npmjs.org/<pkg>) and confirm thedeprecatedfield is set on every targeted version despite the reported error.Reproduced across two npm/node combinations:
Environment