npm documents a route for maintainers who no longer want a package: deprecate it, then transfer it to the registry's own account. Once transferred, the former maintainer can no longer update it. For dependents, that means the package keeps downloading but will never get a fix, so you should plan a replacement.
What the documentation says
The npm page on deprecating packages says that if you no longer wish to maintain a package, you can deprecate it, which prints a message in the terminal when a user installs it. The message can say anything, for example pointing to a supported alternative. The page strongly recommends deprecating over unpublishing, because unpublishing removes a package from the registry entirely, so anyone who relied on it can no longer use it, with no warning.
For a package that other users still depend on, the page adds an option. A maintainer can transfer the deprecated package to the registry's account, which removes it from their profile. A note states that once you transfer a package to the npm account, you can no longer update it.
The transfer takes two commands in order, run by the current owner:
npm owner add npm PACKAGE-NAME
npm owner rm USER PACKAGE-NAME
What this means for dependents
| Event | Effect on you |
|---|---|
| Package deprecated | Installs print a warning, builds keep working |
| Whole package deprecated | It drops out of search results on the website |
| Package transferred to the registry account | No one can publish a new version, so no fixes ever arrive |
The last row is the important one. A transferred package is stable in the sense that nobody can take it over or change it, which closes the door on a hostile takeover of an abandoned name. But it is frozen. Any vulnerability found later will not be fixed upstream.
How to spot it
Run an install and read the output, or check the package page. A deprecation message shows there, and the maintainer list may show the registry account. Also check the last publish date and the repository status.
Steps for dependents
- Search your lockfile for deprecation warnings, not just vulnerabilities.
- For each deprecated dependency, read the message to see whether a replacement is named.
- Estimate the work to replace it, and who owns that work.
- If replacement is not possible soon, record the exception with an expiry date.
- Watch advisories for the package, because fixes will not come from upstream.
- As a last resort, consider vendoring or forking with a named owner, and say so in your policy.
For maintainers stepping away
Deprecate with a clear message first. Name a replacement if one exists. Decide whether freezing the package under the registry account is better for users than naming a successor, because it gives them certainty, but also ends all fixes.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how a package's status is presented in the inventory, and think about where a deprecation notice would show.
Quick check
Does deprecating a package break installs?
No. The message is printed, and builds keep working.
Can the original maintainer undo a transfer?
After transfer they can no longer update the package. The page does not describe a reversal, so ask npm support.
Is unpublishing better?
The documentation says it recommends deprecating instead, because unpublishing can break users without warning.
How Safeguard helps
Safeguard can help you keep the support dates in view. Its SBOM and dependency scanning list the exact versions you run, reachability analysis shows which known issues your code can actually reach, and policies and gates can stop a build that pulls in a version you have decided to retire. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can try the free scan on a manifest first.
Sources
- npm Docs, Deprecating and undeprecating packages or package versions: deprecation and transfer to the npm account. Fetched 19 October 2026.
Last reviewed: 19 October 2026.
