Deprecate and retire

Abandoned packages keep installing forever. Someone runs npm install @acme/slugify-title years after you moved on and gets silent bitrot. Retirement is part of the contract too.

Plan the end before you need it.

Announce early

Post a retirement notice in the README and in release notes:

• replacement package or approach
• last version that receives fixes
• date when you stop responding to issues
• whether security reports are still accepted

Give people months, not days, when the package has real users.

Deprecate with a useful message

npm deprecate @acme/slugify-title@"<2.0.0" "Package retired. Use @acme/text-slug instead. See https://github.com/acme/slugify-title#migration"

Run a fresh install to see the warning:

npm install @acme/[email protected]

npm prints the deprecation message during install. That is the goal.

Final housekeeping

Remove publish tokens and CI publish jobs so nobody accidentally ships a ghost release. Archive the git repo read-only if the org allows it. Keep the npm scope claimed if squatters might reuse the name.

Do not unpublish old versions without understanding broken lockfiles. Deprecation plus a clear successor is kinder to the ecosystem.

If @acme/text-slug is the replacement, link to a migration guide with import renames and behavior differences. Test that guide on a real downstream project before you publish it.

Retiring well is maintainership. Consumers remember the packages that told them what to do next.

Leave one final patch release that updates the README banner and changelog even if no code changed. That version gives search engines and npm metadata a fresh pointer to the successor.

If you must transfer ownership instead of retiring, use npm owner add and confirm the new maintainer published at least one tested release before you remove yourself.