NPM-DISPUTES(7)

💅 npm-disputes(7) — the whole "someone took my package name" situation, explained by your bestie

okay so this is npm-disputes(7), which is genuinely the most "we can settle this with a respectful email" manpage in the entire npm universe. it's all about Handling Module Name Disputes — like when you want a package name and somebody else already has it. no cap, it's mostly emotional intelligence and like 3 commands. let's go 💖

---

✨ SYNOPSIS ✨

the entire playbook, in three steps, literally:

1. Get the author email with npm owner ls <pkgname>

2. Email the author, CC support@npmjs.com

3. After a few weeks, if there's no resolution, we'll sort it out.

and then the thesis statement of the whole page, which is honestly iconic:

Don't squat on package names.  Publish code or move out of the way.

like. that's it. that's the vibe. 🫶

---

🌸 DESCRIPTION 🌸

so sometimes a user publishes a module, and then later some other user is like "hey I want that name actually." and there are like, a bunch of ways this happens. every single one of these is based on actual events, which is sending me 😭. here they are:

1. Joe writes a JavaScript module foo, which is not node-specific. Joe doesn't use node at all. Bob wants to use foo in node, so he wraps it in an npm module. Some time later, Joe starts using node, and wants to take over management of his program.
2. Bob writes an npm module foo, and publishes it. Perhaps much later, Joe finds a bug in foo, and fixes it. He sends a pull request to Bob, but Bob 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. Joe would like to publish a new foo, but can't, because the name is taken.
3. Bob writes a 10-line flow-control library, and calls it foo, and publishes it to the npm registry. Being a simple little thing, it never really has to be updated. Joe works for Foo Inc, the makers of the critically acclaimed and widely-marketed foo JavaScript toolkit framework. They publish it to npm as foojs, but people are routinely confused when npm install foo is some different thing. 💀
4. Bob writes a parser for the widely-known foo file format, because he needs it for work. Then, he gets a new job, and never updates the prototype. Later on, Joe writes a much more complete foo parser, but can't publish, because Bob's foo is in the way.

now bestie, listen — the validity of Joe's claim in each situation can be debated 🙈. however (and this is the main character energy part), Joe's appropriate course of action in each case is the same. same three steps, every time:

1. npm owner ls foo. This will tell Joe the email address of the owner (Bob).
2. Joe emails Bob, explaining the situation as respectfully as possible, and what he would like to do with the module name. He adds the npm support staff support@npmjs.com to the CC list of the email. Mention in the email that Bob can run npm owner add joe foo to add Joe as an owner of the foo package.
3. After a reasonable amount of time, if Bob has not responded, or if Bob and Joe can't come to any sort of resolution, email support support@npmjs.com and we'll sort it out. ("Reasonable" is usually at least 4 weeks, but extra time is allowed around common holidays.)

lowkey the whole page is just "be a decent person and send an email" and honestly? slay.

---

🦋 REASONING 🦋

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. like, they're not villains, they're just living their life 😭💖

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. 🥹 that's the good stuff fr fr.

---

🔥 EXCEPTIONS 🔥

okay but here's where the vibe check turns serious. 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:

1. Malware (that is, a package designed to exploit or harm the machine on which it is installed).
2. Violations of copyright or licenses (for example, cloning an MIT-licensed program, and then removing or changing the copyright and license statement).
3. Illegal content.
4. "Squatting" on a package name that you plan to use, but aren't actually using. Sorry, I don't care how great the name is, or how perfect a fit it is for the thing that someday might happen. If someone wants to use it today, and you're just taking up space with an empty tarball, you're going to be evicted. 👋
5. Putting empty packages in the registry. Packages must have SOME functionality. It can be silly, but it can't be nothing. (See also: squatting.)
6. Doing weird things with the registry, like using it as your own personal application database or otherwise putting non-packagey things into it.

🚨 If you see bad behavior like this, please report it right away. fr fr, don't be shy.

---

👑 SEE ALSO 👑

go read these next, bestie:

• npm help 7 registry
• npm help owner

---

and that's the whole page 🎀 periodt. this one's from March 2017, and it's npm-disputes(7) — go forth, be respectful in your emails, CC support@npmjs.com, wait your 4 weeks, and whatever you do, don't squat on names. mwah 💜✨