Excuse me, but what the fuck?<p>Looks like the line responsible checks if the npm binary is run as sudo and then uses the UID and GID of the invoking user when chowning the directory. [ <a href="https://github.com/npm/npm/blob/latest/lib/utils/correct-mkdir.js#L54" rel="nofollow">https://github.com/npm/npm/blob/latest/lib/utils/correct-mkd...</a> ]<p>I feel like screaming, who thought this was a good idea? If I invoke something as sudo, why does anyone think it should try to detect that and do anything about it? I want to run as the user sudo has set, not my own user, <i>OBVIOUSLY</i>.<p>Don't try to be smart about sudo, you will break stuff.
This is really horrific.<p>The idea that correctMkdir() exists at all seems to me to be so wrong-headed.<p>This comment from the source says a lot:<p><pre><code> // annoying humans and their expectations!
</code></pre>
Good UX is an important, oft-overlooked consideration, but there is definitely such a thing as taking it too far. If your humans are expecting this level of hand-holding, it's because you've trained them to expect it by pandering to them up until now. This is the kind of problem that should be handled with good, detailed, error message display when users don't get the result they expect, not "fixing" it with over-reaching magic.<p>I'm not sure I'd trust anything put out by the npm team in general from hereonin if they genuinely thought creating the correct-mkdir.js file in the first place was a reasonable idea. Is it? Genuinely open to a counter-argument.
There appear to be no unit tests for their entire lib/utils folder. Which includes things like this (misguided) chown utility. <a href="https://github.com/npm/npm/tree/release-next/test" rel="nofollow">https://github.com/npm/npm/tree/release-next/test</a> - and note the lack of testing in the commit linked in the bug report.<p>I had an inkling that NPM was cancer, but not like this.<p>Yarn, by contrast, has everything you would expect of a Facebook-engineered library:
<a href="https://github.com/yarnpkg/yarn/tree/master/__tests__/util" rel="nofollow">https://github.com/yarnpkg/yarn/tree/master/__tests__/util</a><p>Will be closely evaluating a switch to Yarn for our live apps. This is simply sad.
It's been almost 2 years since the great left-pad debacle[0]. The last major npm issue[1] was less than 2 months ago. While the underlying npm registry security issues will remain for a while (and other languages don't seem to have these issues with their package managers), there doesn't seem like there's too much I can do other than use yarn. And hope an alternative registry will appear.<p>Since I 'vote' with my code - this migration page has been helpful today - and I hope it will help others:
<a href="https://yarnpkg.com/lang/en/docs/migrating-from-npm/" rel="nofollow">https://yarnpkg.com/lang/en/docs/migrating-from-npm/</a><p>It took me ~5 mins to migrate all of my code from npm to yarn. But I don't have complex CI tasks either.<p>I use ncu to check updates every couple of days, sometimes more frequently. To further distance myself from npm, can anyone comment on the pros/cons of github repo paths instead of package names in package.json?<p>[0] <a href="https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos" rel="nofollow">https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos</a><p>[1] <a href="https://github.com/npm/registry/issues/255" rel="nofollow">https://github.com/npm/registry/issues/255</a><p>*edit: formatting
I just can't feel sorry for folks when I see comments like this one:<p>> <i>This destroyed 3 production server after a single deploy!</i><p>I do think that the developers have a duty to do some testing of their software before putting out releases/updates. However, <i>users</i> also have a duty to perform sufficient testing before they push new versions to their production environments.<p>In my opinion, it's kinda like losing data because you didn't make and/or test your backups. It's a really crappy way to have to learn a lesson but at least they've finally learned it -- and if they haven't, well, then maybe they will the <i>next</i> time it happens.
Good lord, when I try to follow the link I get the Unicorn error page with the message 'This page is taking way too long to load. Sorry about that. Please try refreshing and contact us if the problem persists.'<p>Has this issue provoked so much outrage that GitHub can't handle the constant stream of angry emojis on the issue comment thread?
Apart from being a horrific bug, why are people running npm as root? Why don't they install it somewhere below $HOME and modify $PATH? npm is working fine without root permissions.<p>Everything is super dangerous as root, one should avoid using root at all costs until there is no other way.
<a href="http://blog.npmjs.org/post/171169301000/v571" rel="nofollow">http://blog.npmjs.org/post/171169301000/v571</a><p><pre><code> Thankfully, it only affected users running `npm@next`, which is part of our staggered release system
#STOPUSINGPRERELEASEWITHSUDO
</code></pre>
Really now?<p><pre><code> #ANGRYORANGEWEBSITE #PEOPLEGOTMAD
</code></pre>
:)
Reminds me of a recent Yarn problem, overwriting which(1).
<a href="https://github.com/yarnpkg/yarn/issues/4205" rel="nofollow">https://github.com/yarnpkg/yarn/issues/4205</a>
Doesn't really surprise me when you have other issues like this (<a href="https://github.com/npm/npm/issues/17929" rel="nofollow">https://github.com/npm/npm/issues/17929</a>) that have persisted for a long time. NPM 5.x in general hasn't been very stable.
Wow the toxicity on that thread is appalling. I feel like I need to a tool when hiring people that automatically shows me their github comments with the most reactions.
Wayback link, of someone has a better mirror please post: <a href="http://web.archive.org/web/20180222170341/https://github.com/npm/npm/issues/19883" rel="nofollow">http://web.archive.org/web/20180222170341/https://github.com...</a>
From: <a href="https://github.com/npm/npm/releases/tag/v5.7.1" rel="nofollow">https://github.com/npm/npm/releases/tag/v5.7.1</a><p><i>"Thankfully, it only affected users running npm@next, which is part of our staggered release system, which we use to prevent issues like this from going out into the wider world before we can catch them. Users on latest would have never seen this!"</i><p>If you are updating to the latest pre-release of something within mere <i>hours</i> of it dropping and you are updating production systems (presumably that have some business value) with no previous testing then the consequences of that aren't on the devs they are 100% on you. And you don't deserve to call yourself an IT (or Ops or DevOps or what-have-you) professional, that is amateurish behavior in the extreme.
My personal opinion is that the root cause of the issue is the ability of a <i>language</i> pacakge manager to mess with system files at all (i.e. do a global install of anything). Shards, the crystal package manager makes the sensible design decision to only install libraries into `$PWD/lib` and binaries into `$PWD/bin`. Everything is local only to your project. If you want a binary on your PATH, you can create an installation method that works for your commandline tool's specific usecase. Hopefully a distro/homebrew package.<p>I wrote about this in longer form here: <a href="https://github.com/crystal-lang/crystal/pull/3328#issuecomment-247970222" rel="nofollow">https://github.com/crystal-lang/crystal/pull/3328#issuecomme...</a>.
npm is one of the few tools that I am afraid to have on my Laptop, Because unlike most tools I have used, When npm does something wrong, It'll ruin not just itself but a lot more directories on my pc which is annoying to fix.
Oh well, I remember fondly that one time I had an important deadline whooshing by (with that lovely sound Douglas Adams knew) and I happened across this cute little bug:<p><a href="http://appleinsider.com/articles/09/10/12/snow_leopard_guest_account_bug_deletes_user_data" rel="nofollow">http://appleinsider.com/articles/09/10/12/snow_leopard_guest...</a><p>(Yeah, it's <i>that</i> much-vaunted Snow Leopard.)<p>I do remember scrambling to recover my backups. Back then, I didn't make full-disk backups, so I had to assemble my user folder from various places. Everything else that transpired that night and the day after remains a haze.
I find it interesting that nobody noticed this before public release. And apparently this version is a pre-release? But that isn't specified on the blog post?
As a semi-outsider to the frontend and node development worlds, it continues to surprise me that a viable alternative to npm still hasn't come along. Not trying to pile more hate on npm, but there's been many years of complaints about instability, horrid UX, bad security model, user hostility, etc. Yarn was just a first step. If there was a system with half the features, but made sense and was secure I think the community would shift very quickly.
I swear NPM has some absurd showstopping bug every month.<p>With something that has as many people using it, it's just... I dunno, it's disheartening.<p>Edit: oh well, this was a @next release only. Not as bad. Still scary.
CI/CD does not mean deploying code to production by fetching source code from GitHub onto a server used by your customers and then compiling or downloading NPM dependencies.<p>That is a recipe for disaster.
Looks at correct-mkdir. Sees "cb = dezalgo(cb)". <a href="https://www.npmjs.com/package/dezalgo" rel="nofollow">https://www.npmjs.com/package/dezalgo</a><p>"Contain async insanity so that the dark pony lord doesn't eat souls"<p>Just... What. I feel like when you need to reach for tools to "contain insanity", you might want to backup and ask someone who has written to a filesystem before... The linked blog about "preventing the release of Zalgo" and the linked <a href="https://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/" rel="nofollow">https://blog.ometer.com/2011/07/24/callbacks-synchronous-and...</a> seem completely erroneous. The entire point of callbacks is to _surrender_ control to a function - here is a piece of code to run when you are ready - now, sometime, or never, or maybe many times, as you see fit. Waiting until the next process tick seems so completely unnecessary... This strikes me heavily as "a solution in desperate search of a problem" - although I have that feeling with a _lot_ of NodeJS code I read...<p>The author of the blog linked on the dezalgo project seems to, at the end of the post, imply the purpose is for performance? By deferring work until a later date?<p>"The basic point here is that “async” is not some magic mustard you smear all over your API to make it fast. Asynchronous APIs do not go faster. They go slower. However, they prevent other parts of the program from having to wait for them, so overall program performance can be improved."<p>Other parts of the program _other than the work we've asked it to do_? What if we're only "correctly making" one directory? So we intentionally make our code slower... So that "other code" can run? He continues:<p>"This makes the API a bit trickier to use, because the caller has to know to detect the error state. If it’s very rare, then there’s a chance that they might get surprised in production the first time it fails. This is a communication problem, like most API design concerns, but if performance is critical, it may be worth the hit to avoid artificial deferrals in the common cases."<p>So it's slower -and- more complicated, and we're gonna hide it behind a meme. Gotcha.
I wish fixing of npm global directory permissions was part of the npm install page (<a href="https://docs.npmjs.com/getting-started/installing-node" rel="nofollow">https://docs.npmjs.com/getting-started/installing-node</a>), or mentioned at least. My first few npm setups always left me in permissions hell as I'd just use the install page, ignoring the next steps.
A user of NPM that needs to use `sudo npm` simply did not properly install nodejs into the user directory. NPM is packaged with the node version you are running. So if you installed node with a root user or in a directory that requires root user access you will need to sudo to use `npm`. But if you properly install node under your user you will never have an issue. Anyone that does `sudo npm` did not install nodejs under their user. This may be confusing to people because a lot of tutorials tell you to use `sudo npm`. NPM is a piece of software that is consumed by millions of people and different devices. It is crazy to think there will be no side effects to how people use something where it was not designed.
Running npm as root is bad, either install the npm package from your distribution (apt, pacman...) or, to use `npm install -g` edit `.npmrc` add `prefix=/home/<me>/.node` in it, and add `~/.node/bin` to your path.
Reading this and the comments here really makes me feel sorry for the npm people.<p>If you are reading this:
You are doing great work, I wish you the energy and strength to ignore the trolls.
Switching to yarn is not going to fix this. However, this raise some concern about npm cli<p>- we are relying on 2 people team for our applications.
- maintainer doesn't seem to care much about this horrific bug: <a href="https://imgur.com/a/v4Ndb" rel="nofollow">https://imgur.com/a/v4Ndb</a>
About a week ago, I attended a tech talk by a Google employee, a senior position, who said, if I remembered correctly, that their testing effort uses the most of their hardware resources at entire Google. Software testing can be difficult and challenging, but it is a critical part.
I just looked at my /usr/lib/node_modules directory and it's No man's land in there and I'm on npm 5.6.0. How could this go unnoticed for so long?