Unable to publish under same name as public registry packages
See original GitHub issueFor 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 noopindex.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.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:3
- Comments:9 (3 by maintainers)
Top GitHub Comments
My workaround/safeguard (which feels fine) is to only publish scoped packages under namespaces I own on the public registry.
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 a1.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 👍