How to Handle Module Name Disputes
In our last tutorial we showed what it takes to publish a package to npm. The tutorial you are about to read will show you the step you should take to resolve module name disputes with other npm publishers.
This tutorial will show you a clarification of the acceptable behavior outlined in the npm code of conduct.
- Use this command: npm owner ls <pkgname> to get the author's email.
- Then, you should email the author, CC [email protected]
- After few weeks, if there is no resolution, npm will sort it out.
There could be situations where a user publishes a module, and then some other user wants to use that name. below are common ways this can happen:
- Jane writes an npm module jump, and publishes it. Perhaps much later, James finds a bug in jump, and fixes it. He sends a pull request to Jane, but Jane doesn't have the time to deal with it, because she has a new job and a new baby and is focused on her new Erlang project, and she is kind of not involved with node any more. James would like to publish a new foo, but can't, because the name is taken by Jane.
- Jane writes a parser for the widely-known jump file format, because she needs it for work. Then, she gets a new job, and she never updates the prototype. Later on, James writes a much more complete jump parser, but he can't publish, because Jane's jump is in the way.
- npm owner ls jump. This tells James the email address of the owner (Jane).
- James emails Jane, explaining the situation as respectfully as he can, and what he would like to do with the module name. He adds the npm support staff [email protected] to the CC list of the email. Mentioning in the email that Jane can run npm owner add james foo to add James as an owner of the jump package.
- If Jane has not responded after a reasonable amount if time, or if Jane and James can't come to any sort of resolution, James will have to email support [email protected] and they will sort it out. ("Reasonable" is usually a period of at least 4 weeks.)
Most times people do not want to stand in the way of other people, so npm allows communicate effectively with ourselves without major intervention, that way npm does not end up hurting well-meaning admins.
There are things that are not allowed, and they will be removed without discussion by npm if they are brought to the attention of the npm registry admins, they include but are not limited to:
- Malware (that is, if the package is designed to harm or exploit the machine on which it is installed).
- Violations of licenses or copyrights (for example, if you clone an MIT-licensed program, and then remove or change the copyright and license statement).
- Illegal content.
- "Squatting" on a package name which you plan to use, but you are not actually using. Sorry, npm does not care how great the name is, or how perfectly it fits with the thing that you will do someday. If someone needs to use it today, and you are just taking up space with an empty tarball, you will be evicted.
- Putting empty packages in the npm registry. All Packages must have SOME functionality. Your package can't be nothing.
- Doing weird things with the npm registry, such as using it as your own personal application database or putting non-packagey things into it.
- Other things that are forbidden by the npm Code of Conduct such as hateful language, pornographic content, or harassment.
If you see bad behavior such as this, please report them to [email protected] instantly. Do not attempt to resolve abusive behaviors personally.
If you think that another npm publisher is infringing your trademark, like using a confusingly similar package name, you should email [email protected] with a link to the package or the user's account on https://www.npmjs.com/. You should also attach a copy of your trademark registration certificate.
If npm sees that the package's publisher is intentionally misleading others by misusing your registered mark without permission, they will transfer the package name to you. Otherwise, they will contact the package publisher and ask them to clear up any confusion with changes to their package's README file or metadata.
- Weekly Trends
- Python Interview Questions and Answers: Comprehensive Guide
- Scala Exercises, Practice, Solution
- Kotlin Exercises practice with solution
- MongoDB Exercises, Practice, Solution
- SQL Exercises, Practice, Solution - JOINS
- Java Basic Programming Exercises
- SQL Subqueries
- Adventureworks Database Exercises
- C# Sharp Basic Exercises
- SQL COUNT() with distinct
- Java Collection Exercises
- SQL COUNT() function
- SQL Inner Join