Unable to publish under same name as public registry packages

[Justin Russell]

For example, with this package.json:

{
  "name": "react",
  "version": "99.99.99",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

Basically I:

• Created a new folder called "react"
• Ran npm init + created a silly noop index.js file
• Updated the version number to something big
• Ran npm publish --registry my-registry.com

The npm cli tells me version 99.99.99 was added and indeed I see the tarball in s3.

However, when I go to install this package, it cannot be found. E.g. npm install react@99.99.99 --registry my-registry.com fails because the specified version cannot be found. When I inspect my package information in s3, sure enough version 99.99.99 is not listed as available.

Shadowing an existing module name may not be a supported use case, that's cool, but what's not so great is that there's nothing stopping someone from installing a module on the public registry that clobbers one of my private package names. When this happens any time I install a new version of my private module all it's prior meta information gets clobbered with whatever is on the public registry.

[Justin Russell]

My workaround/safeguard (which feels fine) is to only publish scoped packages under namespaces I own on the public registry.

[Avaer Kazmer]

Thanks for the workaround hack @jtrussell!

It does make the whole thing a bit messy if you want to use npm-register as a public-facing registry for users though.

[Jeff Dickey]

This is by design (though maybe there could be better documentation and/or behavior around it). registry.npmjs.org is supposed to be the source of truth with npm-register providing additional packages. @jtrussell mentions the best way around it.

[Justin Russell]

@dickeyxxx perhaps it would be reasonable for a publish to fail (loudly) if the name in question already exists in the publish registry? I'd be interested in putting a PR together if that sounds reasonable. I'm not sure I'd consider this a breaking change as the "successful" publishes never resulted in usable versions of the package.

[Jeff Dickey]

definitely down for that @jtrussell. There is still an outstanding issue of someone later publishing a package, but that's a good first step.

[Justin Russell]

Haven't forgotten about this but was wondering on a possible solution to the other half of the issue. How about a configurable blacklist of package names/patterns to ignore from the uplink registry? E.g. I could:

• Tell npm-register to ignore 'react' on the uplink registery so that I can publish my own version here.
• Ignore packages matching /^@acme\/.*$/ so I can safely publish under that scope even if someone else grabbed it on the public registry.
• Ignore packages 'lodash' and 'underscore' because e.g. my my company decided our apps shouldn't use them.

[Jeff Dickey]

👍 sounds like a good solution

[Dan Gautsch]

@jtrussell good solution, I'll look to add this to a roadmap after the UI is done.

[Gilles De Mey]

Hey folks, just got bitten by this today.

We've always published our beta versions <1.0.0 on our own private repository and decided to release a 1.0.0 version and also make that available publicly on the official NPM registry.

To my surprise our existing internal builds started failing when they couldn't find the older versions of our scoped package.

Any ideas on how to force it to accept packages? :)

EDIT:

For posterity, we've managed to work around the issue by renaming our package and publishing that to the NPM registry 👍