One of my NPM modules is, frankly, pretty lame, hasn't been worked on in years, has no watchers, no stars, and only ~50 downloads per month. I'm going to abandon it, and eventually delete it so it doesn't clutter up my github page. Just in case there's one project in the world relying on it, is there a good way to let users know that? Some standard phrase for the README file?

"Free to good home"?

2 Answers 2


TL;DR: Don't kill a puppy, give it up for adoption instead.

The point of publishing a library is not the fame and glory. The point is contributing some useful functionality. Since you have published your work in a package manager, you have allowed others to depend on it.

The number of stars and downloads is irrelevant. Typically, many dependencies are hidden, non-public, and many users don't have an account that would allow them to star your project. Even if they did have an account, they might not want to publicly associate themselves with your project. You gain nothing by deleting the package, but would cause a major headache for your users, even if there's only a single user.

A deletion is only sensible in three cases:

  • You are forced to remove the code for legal reasons, e.g. if you published material that you weren't allowed to publish.

  • You are ashamed of the project. It is of such abysmal quality or is a joke in bad taste, and you don't want to be associated with it. A project that no one uses would be neutral or positive, but such a horrible module would have noticeable negative effects for a job search.

  • The code is fundamentally broken at a design level. It is not possible to use the code safely, and it will put users in danger.

Those points do not seem to apply here. So you just don't want to maintain the module, since it doesn't feel very rewarding. That is OK. Publishing something as open source does not obligate you to pour more effort into the project than you want to; it is perfectly OK to stop any maintenance. In that case, don't delete it, just be honest with prospective users.

If the module is simply not great but you know of better alternatives, link to them from your README and all relevant landing pages.

Status of this module

This module is deprecated. Please use other-module instead. It is more mature, better tested, and offers additional-features. That project doesn't have missing-feature, but you can use workaround.

If you just don't want to do any further maintenance, just say so:


This project is no longer being maintained, and I'm no longer fixing bugs. Please contact me if you want to adopt this project. You can also fork it on GitHub.

Runtime deprecation warnings should be avoided since they are a very drastic measure. While they have more visibility than an additional paragraph in your documentation, they should only be used if something is about do break in an upcoming version. Since there's no upcoming version in your case, such warnings don't make any sense. Note also that such warnings will be invisible if users have cached a specific version of your module in a personal module registry, as would be sensible.

A typical node module is very small. You're not costing NPM or GitHub significant storage space or bandwidth with your project. Your GitHub user profile only lists your most popular repositories, so deleting unpopular ones does not de-clutter it. You'd be doing no one – NPM, your users, or your own reputation – a favour by completely deleting your module.


Here's a couple of things I see people do for any project:

  • Release a patch version that gives off a huge warning in the console that this project is deprecated, and no further support will be provided when it breaks.

  • Huge warning in README.md to reflect the deprecation. Reason can be written the README.md, on an issue, or on the wiki.

  • Set repo redirects when you want to take down the repo.

  • Sometimes people just leave the repo intact for historical reference and not to break the entire ecosystem. You don't want to be the next leftpad.

Here's some good examples:

  • 2
    Hmm, it took me awhile to figure out that Jade is now Pug2 (three hops in the web browser). Componentjs also took 3 clicks. Jam is the only one that is clearly and obviously marked as deprecated. Nov 28, 2016 at 15:40
  • Yes - one of the two things that turned me off from Jade was the endless name changes. The other is that I prefer visible { or < vs. using invisible space to give meaning.
    – user949300
    Nov 29, 2016 at 1:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.