npm ERR! Windows_NT 6.1.7601
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "update"
npm ERR! node v4.0.0
npm ERR! npm v2.14.2
npm ERR! code E404
npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/less-sprites
npm ERR! 404
npm ERR! 404 'less-sprites' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.
The issue appeared after update to node 4.0.0 (npm v2.14.2) from node 0.12.7 (npm v2.11.3).
@kenany Yes, npm update works well if I add private: true to package.json of already installed less-sprites.
Should I always set the private flag for cloned projects? I mean is it my fault I ran into this issue because I didn't read the docs carefully, or is it an npm error?
@subzey Well, npm outdated (which is what npm update internally uses) traverses through your installed dependencies and queries the registry for each one that is not designated as private. Maybe a case could be made for making it smarter, such as recognizing when one has installed a tarball from GitHub instead of the registry by looking at the _from/_resolved fields:
"_resolved": "https://github.com/multicharts/less-sprites/archive/master.tar.gz",
"_from": "https://github.com/multicharts/less-sprites/archive/master.tar.gz"
But perhaps a case could also be made for not doing this. Maybe someone out there wants to know when the version they are getting from GitHub is older than the version in the npm registry.
Personally I am leaning towards the current behavior being my own expected behavior (especially since I am the one who submitted the patch that made npm outdated ignore private packages, because I was getting tons of 404 errors when I used private, local modules).
I think you're right. But on the other hand if someone installed a package named foo from tarball on GH, that person shouldn't care about the fact central repo also contains (or doesn't contain) a package named foo. Or the private flag is designated to be a some kind of namespace?
I suppose you can close this issue if you're sure npm works as expected.
This behavior change from 0.11 to 0.14 2.11 to 2.14 is (formally) a breaking one introduced in a minor semver version, which is bad. But reverting it would introduce another breaking change, which is worse.
@subzey We can wait for a core developer to comment on this if anything :)
from 0.11 to 0.14
Hmm, you mean [email protected] to [email protected]?
This behavior is quite frustrating. I have tarball deps for little utilities that don't need to be private, but also aren't important to publish at the moment.
I rely upon npm outdated constantly and seeing this fixed would make my day.
This bug still exists in npm 4.0.0.
Expected behaviour:
If I include "some-random-package-not-in-registry": "http://myurl.com/package.tar.gz" in my dependencies, npm update should look for updates for that package in http://myurl.com/package.tar.gz.
Current behaviour:
Instead, npm update looks for updates for that package in the npm registry, even though I have specifically told it to look for it in http://myurl.com/package.tar.gz. Even worse, the whole npm update actually fails due to the package not appearing in the registry.
We're closing this issue as it has gone thirty days without activity. In our experience if an issue has gone thirty days without any activity then it's unlikely to be addressed. In the case of bug reports, often the underlying issue will be addressed but finding related issues is quite difficult and often incomplete.
If this was a bug report and it is still relevant then we encourage you to open it again as a new issue. If this was a feature request then you should feel free to open it again, or even better open a PR.
For more information about our new issue aging policies and why we've instituted them please see our blog post.
