The npm Blog

The npm CLI project does not have designated LTS releases. The project only regularly does releases to the most recent major release.

Security Issues

In the event of a security issue, the npm CLI project will back port security patches to any version of npm currently shipping with a supported Node.js version, that is to say, any Node.js version still in its maintenance window.

Other releases

From time to time the npm CLI project may do a release of an older version of npm at the request of the Node.js project. Historically this has only been for important updates to node-gyp.

Using Old npm Versions

These older versions of npm will continue to work with the registry.npmjs.org registry but may not support all of its latest features.

Questions and Comments

Questions or requests to change this policy should be filed as issues on the npm CLI repo, so the discussion can be tracked in one place.

Historical Note

During the npm@3 release cycle, npm@2 was maintained as an LTS release. Support for this version ended when npm@4 was released and no new version was promoted to LTS status.

Q: Hi! Can you state your name and what you do? 

A: Hi there! I’m Dan Gebhardt. I’m a co-founder of Cerebris, which is a small web application consulting firm I run with my brother Larry Gebhardt. We’re pretty heavily into open source — I’m on the core teams for Ember.js, Glimmer.js, the JSONAPI spec, and Orbit.js.

How’s your day going?

Whew, it’s a hot one today in New Hampshire! But things are going well. I’m putting some finishing touches on a docs site for Orbit, which feels good because it’s been so long in the making.

What is your history with npm?

Although I’ve been working on web apps for a very long time, I haven’t done much Node development. As a result, I’ve only become a regular npm user in the past few years as it’s gained traction for front-end development. During that time, I’ve been really pleased to see how quickly npm has matured. And not just the npm service, which seems to have scaled quite well, but also the CLI, which is getting both faster and more deterministic (yay lockfiles!). 

What problem did you have that npm Orgs helped you fix?

Tom Dale and I started developing Glimmer.js as a standalone component library separate from Ember in late 2016. Although Ember itself is architected very modularly, the core framework does not feel very modular in practice because of the way it is currently published and typically consumed. When building Glimmer.js we quite deliberately decided to package and publish it as modularly as possible from the start. We not only wanted to share as much as possible between Ember and Glimmer — we also wanted to make packages as useful as possible on their own.

We chose to publish all of the core Glimmer packages through the @glimmer Org. This means that “official” packages all get an authoritative scope that differentiates them from non-scoped community packages. Furthermore, developers can use different packages, such as the dependency injection library @glimmer/di, independent from the rest of Glimmer.

How’s the day-to-day experience of using Orgs?

There’s very little friction to working with Orgs. As the rest of the Ember core team has gotten involved in developing Glimmer, assignments and authorization have been simple and straightforward. As packages are published, core team members are automatically assigned rights, which reduces the overhead of creating and managing packages. 

The only extra thing to remember about scoped packages is that they are private by default. So it’s necessary to explicitly publish packages with public access using `npm publish –access=public`. This is not a problem though, since you only have to remember this on the initial publish (and it’s no doubt a good safety check).

How would you see the product improved or expanded in the future?

I like using the npm CLI to manage packages, teams, and assignments, but a more interactive dashboard would be nice. Have I mentioned Ember.js? ;)

Would you recommend that other groups or companies use Orgs?

Most definitely. I can recommend Orgs for multi-package open source projects, even if they only have one member, because of the clarity that scoped packages provide to a community. Once you have multiple developers working on a project, you also gain the benefits of permission management. And even though I’ve only used Orgs for open source packages, I can easily see wanting to use private Orgs as well to get the same benefits for proprietary code.

What’s your favorite npm feature/hack?

I’ve become a real fan of using lerna for multi-package “mono-repos.” Lerna nicely solves the problem of managing dependencies across several local packages. Instead of needing to `npm link` them all individually, lerna can link them all together with one “bootstrap” command. It’s also quite useful for publishing multiple packages at once.

What is the most important/interesting/relevant problem with the JavaScript package ecosystem right now? If you could magically solve it, how would you?

A few months ago I would have said lockfiles, but I’m grateful that yarn and npm 5 have jumped that hurdle already. 

Instead, I’ll give a rather boring answer: I think we need more rigorous conventions for defining the entry points to our packages. In this era of advanced build tooling and transpilers, the current conventions around defining `main`, `module`, and even `types` in `package.json` seem inadequate. Stronger conventions could identify distributions by language (e.g., TypeScript), language level (e.g., ES5), and module format (e.g., commonjs). This would allow for automatic discovery of the least lossy version of sources appropriate for any given application, and allow for the most optimized JavaScript to be shipped to browsers using tools like babel-preset-env.

Any cool npm stuff your company has done that you’d like to promote?

Nothing specific to npm tooling, just lots of exciting stuff happening in the @glimmer, @ember, and @orbit Orgs :)

Hey y'all. This is another minor patch release with a variety of little fixes we’ve been accumulating~

• f0a37ace9 Fix npm doctor when hitting registries without ping. (@zkat)
• 64f0105e8 Fix invalid format error when setting cache-related headers. ([@Kat Marchán](https://github.com/Kat Marchán))
• d2969c80e Fix spurious EINTEGRITY issue. (@zkat)
• 800cb2b4e #17076 Use legacy from field to improve upgrade experience from legacy shrinkwraps and installs. (@zkat)
• 4100d47ea #17007 Restore loose semver parsing to match older npm behavior when running into invalid semver ranges in dependencies. (@zkat)
• 35316cce2 #17005 Emulate npm@4’s behavior of simply marking the peerDep as invalid, instead of crashing. (@zkat)
• e7e8ee5c5 #16937 Workaround for separate bug where requested was somehow null. (@forivall)
• 2d9629bb2 Better logging output for git errors. (@zkat)
• 2235aea73 More scp-url fixes: parsing only worked correctly when a committish was present. (@zkat)
• 80c33cf5e Standardize package permissions on tarball extraction, instead of using perms from the tarball. This matches previous npm behavior and fixes a number of incompatibilities in the wild. (@zkat)
• 2b1e40efb Limit shallow cloning to hosts which are known to support it. (@zkat)

npm’s documentation recommends that you use semantic versioning, which we also call semver, but it doesn’t explain why you’d use SemVer in the first place.

This post is a quick overview of SemVer and why it’s a good idea.

What is SemVer, again?

At its most basic, SemVer is a contract between the producers and consumers of packages that establishes how risky an upgrade is — that is, how likely it is that an upgrade will break something. The different digits that comprise a SemVer version number each have meaning, which is where the “semantic” part comes from.

There’s a great deal of nuance to the full semver specification but it takes just a few seconds to review the core idea.

A simple semver version number looks like this: 1.5.4. These three numbers, left to right, are called:

• major
• minor
• and patch versions.

A more descriptive way to think of them is as:

• breaking
• feature
• and fix versions.

You release a major version when the new release will definitely break something in users’ code unless they change their code to adopt it. You release a minor version when you introduce a feature that adds functionality in a backwards-compatible way, i.e., you add a feature that doesn’t require users of the previous versions to change their code. You release a patch version when you make a backwards-compatible bug fix, like closing a security flaw or correcting the code to match documented behavior.

By separating releases by risk, SemVer allows the consumer of the software to set rules about how to automatically pull in new versions.

A pretty common set of rules when using a library in development is:

• I won’t accept any breaking changes.
• I will accept new features if they’re not breaking.
• I will accept any fixes if they’re not breaking.

When using npm, you can express this set of rules by listing a package version as ^1.3.5 or 1.x. These are the default rules npm will apply to a package when you add it to your project’s package.json. npm@5 ensures that this happens automatically when you run npm install.

However, you might not care about new features as long as there are no bugs:

• I won’t accept any breaking changes.
• I don’t need any new features.
• I will accept any fixes if they’re not breaking.

You would express those rules in npm using a range like ~1.3.5 or 1.3.x. You can make this the default behavior of npm using the save-prefix configuration option.

The best formulation of rules isn’t 100% clear: a fix version isn’t guaranteed not to break your code, the author just doesn’t think it will. But excluding fix versions entirely might leave you open to a known security problem, in which case your code is “broken” simply by staying as-is.

Many people accept feature and fix versions in development, but lock down the packages they depend on to exact, known-good versions once in production by using the package-lock.json feature of npm@5.

Why is SemVer a good idea?

SemVer allows you — and npm — to automatically manage, and thus reduce, the risk of breaking your software by baking information about relative risk into the version number. The key word here is automatically.

Imagine if everybody used a single number for their version, which they incremented every time they made any kind of change. Every time a package changed, you would need to go to the project’s home page or changelog and find out what changed in the new version. It might not be immediately clear if that change would break existing code, so you would have to ask the author or install it and test the software to find out.

Imagine instead if everybody used a single number for their version and incremented it only when they’d added a bunch of new features that they were really proud of. This would be even worse. Not only would you not know if a change was going to break your code, but if an update did break your code, you’d have no way of specifying that you wanted a specific earlier version.

Either of these extreme alternatives would be painful for the consumers of a package, but even more painful for the author of a package, who would constantly be getting inquiries from users about how risky an upgrade was. A good author might put that information in a known place on their home page, but not everyone might be able to find it.

By making this form of communication automatic, SemVer and npm save everybody involved a great deal of time and energy. Authors and users alike can spend less time on emails, phone calls, and meetings about software, and more time writing software.

SemVer changed the way we write JavaScript

It’s common for a modern JavaScript project to depend on 700–1200 packages. When you’re using that many packages, any system that requires you to manually check for updates is totally unworkable, making SemVer critical — but SemVer is also why there are that many packages in the first place.

10 years ago, the JavaScript world was dominated by a handful of very large libraries, like YUI, Mootools, and jQuery. These “kitchen sink” libraries tried to cover every use case, so you would probably pick one and stick with it. Different libraries were not guaranteed to work well together, so you’d have to consider compatibility before adding a new one to your project.

Then Node.js came along, and server-side JavaScript developers began using npm to add new libraries with very little effort.

This “many small modules” pattern became hugely popular, and npm’s automatic use of SemVer allowed it to blossom without software being constantly broken by unexpected changes. In the last few years, tools like webpack and babel have unlocked the 500,000 packages of the npm ecosystem for use on the client side in browsers, and the pattern proved equally popular with front-end developers.

The evidence suggests that using a large number of smaller modules is a more popular pattern than a handful of large libraries. Why that’s the case is up for debate, but its popularity is undeniable, and SemVer and npm are a big part of what make it possible.

Q: Hi! Can you state your name and what you do?

A: Ahoy, I’m Alistair Brown and I’m a lead front-end engineer at ShopKeep, primarily focusing on our BackOffice app, which enables more than 23,000 merchants the ability to manage their business operations from anywhere. With ShopKeep’s BackOffice, business owners manage everything from inventory management to accessing customized reporting specific to their business, so this a vital component to the ShopKeep product.

How’s your day going?

It’s going pretty well — my team is mostly front-end focused, so we use npm many times every day. We’re currently prepping some dependency upgrades to make sure we’re ready to jump on the newest version of React (v16) when it’s released. It’s important to us that we stay up to date, getting the benefits of optimization, bug fixes, and new tools.

What is your history with npm?

I’ve used npm in a few jobs to manage dependencies as well as publish some personal projects as modules on the npm registry. A few years ago, I was given an iKettle for Christmas and spent much of that holiday creating an npm module so I could boil water remotely using JavaScript — not a very popular module, but a lot of fun to build! More recently, I’m excited about the release of npm5. We’ve just rolled it out across our developer machines and onto the CI servers, and we’re really seeing the benefits.

What problem did you have that npm Orgs helped you fix?

The main problem we wanted to solve was being able to share code between upcoming projects. The npm Organization setup allowed us to create our own modules and keep control over who could access them. Having private packages within the organization has allowed us the freedom to create a versioned module, but without the fanfare of opening it up to the world.

Can you tell us a story about a specific package you wanted to make that private packages really enabled you to do?

At Node.js Interactive Europe last year, I’d been inspired by a talk by Aria Stewart, called “Radical Modularity.”  With the concept of “anything can be a package” in mind, we first started small with our brand colours (JSON, SASS, etc.) and configs. I explored pulling these components out of our code base into separate modules as part of a Code Smash (our internal hackathon). This allowed us to test the waters. As we mainly write in React and had created a number of generic components, there were lots of packages we wanted to extract. In the end, we started modularizing everything and have even extracted out our icon assets.

How’s the day to-day experience of using private packages and orgs?

It’s super easy. Day to day, there’s no difference from using any other package from npm. Once the code is out in a module, we get to treat it just like any other piece of third-party code. There had been a little bit of fear that the scope prefix would cause problems with existing tooling, but so far there have been no problems at all — a great feat!

Does your company do open source? How do you negotiate what you keep private and public?

We have several repositories of useful tools that we’ve open-sourced on GitHub, hoping these same tools could be useful for other developers. These range from shpkpr, a tool we use for managing applications on marathon and supporting zero-downtime deploys, to our air traffic controller slack bot, which helps us coordinate deployments to all of the different services we run. Open sourcing a project is an important undertaking and we always want to make sure that we have pride in what we release. Using private packages gives us that middle ground, allowing us to separate out reusable code but keep it internal until we’re ready to show it off.

To people who are unsure how they could use private packages,how would you explain the use case?

We started off wanting to get code reuse by sharing code as a package. Making private packages allowed us to be more confident about pulling the code out, knowing it wasn’t suddenly visible to the world. Our ESLint config is a nice example of a small reusable module we created, containing rules which enforce our internal code style. Splitting this out allowed us to apply the rules across multiple codebases by extending from this central config. Later, we added a new rule, and having immutable packages meant we could cut a new version and stagger the updates to dependent projects. Really, we get all the benefits that you’d expect from using a third-party package, while keeping control of updating and distribution.

How would you see the product improved or expanded in the future?

With the rapid development of the JavaScript ecosystem, it can be hard to keep up to date with new versions as they come out. The `outdated` command helps towards this, but anything that can be built to help developers stay on the latest and greatest would be really handy.

Would you recommend that other groups or companies use Orgs?

Definitely! It’s not just so you can use private packages, it’s also a great way to group your modules under a brand and avoid naming clashes. With the recent pricing change making organizations free, there really is no excuse for open source groups and companies not to publish their modules under an org.

What’s your favorite npm feature/hack?

I’m a huge fan of npm scripts. It’s allowed us to provide a single interface for useful commands and avoid forcing developers to install global dependencies. From building our application with gulp, upgrading tooling with a shell script, to publishing multiple modules with lerna, the developer experience stays the same by hiding the internals behind the simplicity of `npm run`.

What is the most important/interesting/relevant problem with the JavaScript package ecosystem right now? If you could magically solve it, how would you?

Building a package manager is a difficult problem to solve and it’s great to see so much engagement in this space. Deterministic installs is something that has been really important, so it’s good to see this in npm5 and yarn. I think the natural next step is a client-agnostic lock file. When there are multiple developers on a project, making sure that we can replicate a development environment across all dev machines and CI servers is very important — we use a shrinkwrap file (moving soon to a package-lock.json!), but those are npm-specific. Reducing that barrier between different packaging clients should allow for more experimentation on new approaches and optimisations.

Any cool npm stuff your company has done that you’d like to promote?

No — we’re just happy users!

The npm cli GitHub project is one of the most active on all of GitHub. The npm cli team is made up of two people, Rebecca Turner and Kat Marchán. At the time of this writing there are 3,244 open issues in the issue tracker. That’s clearly more issue than a team of two can reasonably handle, even with the invaluable help of the community. It’s even more untenable when you consider that this team is the team fixing the vast majority of the bugs and implementing new features.

Prior to January of 2017 some effort was made to try work the issue tracker while still working on the cli. That was put aside so that we could focus on npm@5. Ongoing we can not and do not want to continue ignoring the issue tracker. Even with its overwhelming size it’s extremely helpful.

So in an attempt to make it serve our team better we’re going to begin automatically closing issues that go too long without activity. This reflects the existing reality that older issues are unlikely to get attention. By making this explicit we hope that it will help ensure that issues that are pain points do not disappear into the churn: If our bots close your issue and it’s still a problem for you, please open a new version of it.

The initial policies are outlined below. We’ll revisit these over time and may adjust some of the numbers. To begin with, we are only considering closing issues that are neither assigned to a team member nor assigned to a milestone. If we do either of those the issue or pull request will stay open.

For issues triaged as support: Issues with no activity for three days will be closed. While we want to give community members an opportuntity to help each other, ultimately this is not the venue for that. You’ll likely be better served by joining something like package.community and asking your questions there.

For issues that have not received any triage (no labels): Issues with no activity for seven days will be closed. Ideally all incoming issues would be triaged but in practice this isn’t practical. Most of these issues are support issues.

For issues that have all other issues: Issues with no activity for thirty days will be closed. If your issue is closed and it’s still a problem for you then we encourage you to open a new issue.

For pull requests: Pull requests with no activity for sixty days will be closed. You are always welcome to open a new pull request (but please rebase on to npm/npm#latest).

This piece is a part of our Customer Convos series. We’re sharing stories of how people use npm at work. Want to share your thoughts? Drop us a line.

Q: Hi! Can you state your name and what you do?

A: Gregor, community manager at the open source project Hoodie, and co-founder at Neighbourhoodie, a consultancy; we do Greenkeeper.

How’s your day going?

I just arrived in Berlin and life is good!

What is your history with npm?

Love at first sight! I’m a big fan of all of what you do! npm is a big inspiration for how a company can self-sustain and be a vital part of the open source community at the same time.

What problems has npm helped you fix?

We love small modules. Because of the maintenance overhead that comes with small modules, we created semantic-release and eventually Greenkeeper. Here is an overview of all our modules.

The `@hoodie` scope allows us to signal that this is a module created by us, the core hoodie team, and that it’s part of the core architecture. I could imagine using the scope in the future for officially supported 3rd party plugins, too.

How’s it going? How’s the day to day experience?

Our release process is entirely automated via semantic-release so that we don’t use different npm accounts to release software. Technically, it’s all released using the https://www.npmjs.com/~hoodie account.

How would you see the product improved or expanded in the future?

Hmm I can’t think of anything… I’ll ask around.

How would you recommend that other groups or companies use npm?

I don’t see why companies would not use scopes. I think it’s a great way to signal an “official” package, in order to differentiate 3rd party modules from the community.

What’s your favorite npm feature/hack?

As a developer, I love that I can subscribe to the live changes of the entire npm registry. It allows us to build really cool tools, including Greenkeeper.

What is the most important/interesting/relevant problem with the JavaScript package ecosystem right now? If you could magically solve it, how would you?

For me, a big challenge is to fix a bug in a library like `hoodie` that is caused by dependency (or sub dependency, or sub sub…). It would be cool if there was a way to easily set up a development environment in which I could test the bug on the main module, but working on the dependency, until I have it resolved. That would make it simple to release a new fixed version of the dependency and the package.json of the main module to request the fixed version.

This is kind of related: let’s say I have a module A with a dependency of module B and B depends on module C, so it’s A=>B=>C. Now, if I fix C and release a new fix version, I cannot release a new version of A that enforces this new version, because it’s a sub-dependency. I’m not sure what the right approach to this problem is, but that’s one that’s bothering me related to npm.

Any cool npm stuff your company has done that you’d like to promote?

Greenkeeper.

Over the last few days we’ve been resetting the passwords for more than a thousand users and sending email informing them of the reset. Here is some detail about why we’re doing this.

We often revoke npm credentials leaked through testing service logs or that were accidentally checked into GitHub. Accidentally leaking environment variables like npm auth tokens in CI logs is a common mistake! We also have reset passwords for users who were found to have used common or weak passwords for their npm accounts, such as their username or the string password.

In this case, however, passwords for a number of users were available online, accessible via Google search. These passwords were made public through security breaches of other sites, and, unfortunately, the owners of some hacked accounts re-used the passwords for their npm accounts. This was discovered by an independent security researcher, who informed us of his discovery and set a short deadline for action on our part before he contacted you himself.

We have reset the passwords and revoked all extant auth tokens for the users whose passwords were publicly available.

To our knowledge, at no time has npm’s account information been accessed inappropriately. In all of these cases, the credentials were leaked either by the npm users themselves accidentally, or in breaches of other sites.

Here are the steps we’ve taken to help protect you from problems like this:

• We’ve implemented stricter password requirements. You can no longer use your own username or words from a list of the most commonly-used passwords.
• We have added additional monitoring and abuse defense on sensitive endpoints, such as the login endpoint, to make dictionary attacks on logins infeasible and detectable.
• We continue to work with Lift Security to audit our services and run penetration tests.
• Leaks are rare, but unavoidable at scale. We will continue to work with white-hat security researchers perform routine scans of this nature, and preemptively protect our community from account leakage.

Here’s how you can protect yourself from credential leaks like this:

• Don’t re-use passwords. Generate a unique password for every site you make an account for.
• Create random passwords using a password manager and have the password manager keep track of them for you.
• Don’t make secret tokens visible in logs when you set up CI services.
• Double-check before you commit configuration files to git. This is a mistake most of us will make at some point, even if we’re careful, so be ready to clean up afterward by changing your passwords.
• Look up your email address on sites like Have I Been Pwned? to see if your credentials have already been leaked online. If they have been leaked, change any passwords you might have re-used.
• Please don’t re-use passwords. Yes, I am repeating this advice. If you re-use passwords, the security of all of your accounts will depend on the practices of the least secure site you visit.

Here’s another patch release, soon after the other!

This particular release includes a slew of fixes to npm’s git support, which was causing some issues for a chunk of people, specially those who were using self-hosted/Enterprise repos. All of those should be back in working condition now.

There’s another shiny thing you might wanna know about: npm has a Canary release now! The npm5 experiment we did during our beta proved to be incredibly successful: users were able to have a tight feedback loop between reports and getting the bugfixes they needed, and the CLI team was able to roll out experimental patches and have the community try them out right away. So we want to keep doing that.

From now on, you’ll be able to install the ‘npm canary’ with npm i -g npmc. This release will be a separate binary (npmc. Because canary. Get it?), which will update independently of the main CLI. Most of the time, this will track release-next or something close to it. We might occasionally toss experimental branches in there to see if our more adventurous users run into anything interesting with it. For example, the current canary (npmc@5.0.1-canary.6) includes an experimental multiproc branch that parallelizes tarball extraction across multiple processes.

If you find any issues while running the canary version, please report them and let us know it came from npmc! It would be tremendously helpful, and finding things early is a huge reason to have it there. Happy hacking!

A NOTE ABOUT THE ISSUE TRACKER

Just a heads up: We’re preparing to do a massive cleanup of the issue tracker. It’s been a long time since it was something we could really keep up with, and we didn’t have a process for dealing with it that could actually be sustainable.

We’re still sussing the details out, and we’ll talk about it more when we’re about to do it, but the plan is essentially to close old, abandoned issues and start over. We will also add some automation around issue management so that things that we can’t keep up with don’t just stay around forever.

Stay tuned!

GIT YOLO

• 1f26e9567 pacote@2.7.27: Fixes installing committishes that look like semver, even though they’re not using the required #semver: syntax. (@zkat)
• 85ea1e0b9 npm-package-arg@5.1.1: This includes the npa git-parsing patch to make it so non-hosted SCP-style identifiers are correctly handled. Previously, npa would mangle them (even though hosted-git-info is doing the right thing for them). (@zkat)

COOL NEW OUTPUT

The new summary output has been really well received! One downside that reared its head as more people used it, though, is that it doesn’t really tell you anything about the toplevel versions it installed. So, if you did npm i -g foo, it would just say “added 1 package”. This patch by @rmg keeps things concise while still telling you what you got! So now, you’ll see something like this:

$ npm i -g foo bar + foo@1.2.3 + bar@3.2.1 added 234 packages in .005ms

• 362f9fd5b #16899 For every package that is given as an argument to install, print the name and version that was actually installed. (@rmg)

OTHER BUGFIXES

• a47593a98 #16835 Fix a crash while installing with --no-shrinkwrap. (@jacknagel)

DOC UPATES

• 89e0cb816 #16818 Fixes a spelling error in the docs. Because the CLI team has trouble spelling “package”, I guess. (@ankon)
• c01fbc46e #16895 Remove --save from npm init instructions, since it’s now the default. (@jhwohlgemuth)
• 80c42d218 Guard against cycles when inflating bundles, as symlinks are bundles now. (@iarna)
• 7fe7f8665 #16674 Write the builtin config for npmc, not just npm. This is hardcoded for npm self-installations and is needed for Canary to work right. (@zkat)

DEP UPDATES

• 63df4fcdd #16894 node-gyp@3.6.2: Fixes an issue parsing SDK versions on Windows, among other things. (@refack)
• 5bb15c3c4 read-package-tree@5.1.6: Fixes some racyness while reading the tree. (@iarna)
• a6f7a52e7 aproba@1.1.2: Remove nested function declaration for speed up (@mikesherov)

An anonymous person recently registered domains that appear to be affiliated with npm, Inc., and in recent days has contacted some npm users to promote a commercial service that our users could confuse for an npm, Inc. product.

npm, Inc. is not affiliated with this individual, we do not endorse these actions, and we are taking action to protect our users and defend our intellectual property rights.

This is what we know:

A few weeks ago, an unknown party registered the domains npm-cdn.com and npm-js.com. They are hosted on DigitalOcean behind the Cloudflare CDN.

npm, Inc. is not affiliated with these domain names, which we believe are an intentional attempt to confuse npm users as to their association with npm, Inc. They are a violation of npm’s trademark policy.

The domains point to sites that run a fork of unpkg, a CDN backend written by Michael J. Jackson. Michael is an upstanding Open Source citizen with whom we have a longstanding relationship. Unpkg is not released under a license that would allow others to use the codebase in this way. The npm-cdn.com and npm-js.com forks are code theft.

A few days ago, the anonymous party began creating a flood of automated accounts on the npm Registry, and created thousands of empty packages that link back to their website. These actions are in violation of npm’s terms of use.

They also have emailed npm maintainers to advertise their product, and BCC’ed other maintainers about packages with which they’re not involved. This is a violation of not only our terms of use, but also common decency.

We have reached out to Cloudflare and DigitalOcean to shut down this abusive behavior. These companies’ processes take some time, and are still underway. As the situation unfolds, we’ll keep the community informed. If you’re not sure whether a piece of communication is really from npm, Inc., contact npm support at support@npmjs.com for assistance.

Supporting the npm Registry and the Open Source community remains our highest priority. We’ll continue to take every possible action to support the community and help developers build amazing things.

— Isaac Z. Schlueter, CEO