This document describes the steps that you should take to resolve module name disputes with other npm publishers. It also describes special steps you should take about names you think infringe your trademarks.
This document is a clarification of the acceptable behavior outlined in the npm Code of Conduct, and nothing in this document should be interpreted to contradict any aspect of the npm Code of Conduct.
npm owner ls <pkgname>
Don't squat on package names. Publish code or move out of the way.
There sometimes arise cases where a user publishes a module, and then later, some other user wants to use that name. Here are some common ways that happens (each of these is based on actual events.)
foo, which is not node-specific. Alice doesn't use node at all. Yusuf wants to use
fooin node, so he wraps it in an npm module. Some time later, Alice starts using node, and wants to take over management of her program.
foo, and publishes it. Perhaps much later, Alice finds a bug in
foo, and fixes it. She sends a pull request to Yusuf, but Yusuf doesn't have the time to deal with it, because he has a new job and a new baby and is focused on his new Erlang project, and kind of not involved with node any more. Alice would like to publish a new
foo, but can't, because the name is taken.
foo, and publishes it to the npm registry. Being a simple little thing, it never really has to be updated. Alice works for Foo Inc, the makers of the critically acclaimed and widely-marketed
foojs, but people are routinely confused when
npm install foois some different thing.
foofile format, because he needs it for work. Then, he gets a new job, and never updates the prototype. Later on, Alice writes a much more complete
fooparser, but can't publish, because Yusuf's
foois in the way.
The validity of Alice's claim in each situation can be debated. However, Alice's appropriate course of action in each case is the same.
npm owner ls foo. This will tell Alice the email address of the owner (Yusuf).
npm owner add alice footo add Alice as an owner of the
In almost every case so far, the parties involved have been able to reach an amicable resolution without any major intervention. Most people really do want to be reasonable, and are probably not even aware that they're in your way.
Module ecosystems are most vibrant and powerful when they are as self-directed as possible. If an admin one day deletes something you had worked on, then that is going to make most people quite upset, regardless of the justification. When humans solve their problems by talking to other humans with respect, everyone has the chance to end up feeling good about the interaction.
Some things are not allowed, and will be removed without discussion if they are brought to the attention of the npm registry admins, including but not limited to:
If you see bad behavior like this, please report it to email@example.com right away. You are never expected to resolve abusive behavior on your own. We are here to help.
If you think another npm publisher is infringing your trademark, such as by using a confusingly similar package name, email firstname.lastname@example.org with a link to the package or user account on https://npmjs.com. Attach a copy of your trademark registration certificate.
If we see that the package's publisher is intentionally misleading others
by misusing your registered mark without permission, we will transfer the
package name to you. Otherwise, we will contact the package publisher
and ask them to clear up any confusion with changes to their package's
README file or metadata.
This is a living document and may be updated from time to time. Please refer to the git history for this document to view the changes.
Copyright (C) npm, Inc., All rights reserved
This document may be reused under a Creative Commons Attribution-ShareAlike License.