
Do not use NPM 5.7 - jguimont
https://github.com/npm/npm/issues/19883
======
zaarn
Excuse me, but what the fuck?

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. [
[https://github.com/npm/npm/blob/latest/lib/utils/correct-
mkd...](https://github.com/npm/npm/blob/latest/lib/utils/correct-mkdir.js#L54)
]

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,
_OBVIOUSLY_.

Don't try to be smart about sudo, you will break stuff.

~~~
reificator
I completely agree with you.

But in fairness, I can't count the number of times that I've needed to fix
things after people treated `sudo npm` as Simon Says[1].

I'm sure they struggled a lot with that issue before coming to this solution.
Was it the right solution? Absolutely not. But that's not the point I'm trying
to make.

It's all too easy to tunnel vision on a particular solution. I've done it
plenty of times, and I'm thankful to those who have helped me to see other
alternatives in time.

[1]: [https://xkcd.com/149/](https://xkcd.com/149/)

~~~
diggan
I don't remember exactly what tool does this, but one package manager (can be
homebrew but long time ago I used homebrew) warns users if you are running it
as root, since it should install packages as the user.

I think npm could implement a similar strategy and educate the users how
packages should really be installed.

~~~
Shank
Homebrew it is!

$ sudo brew

Error: Running Homebrew as root is extremely dangerous and no longer
supported. As Homebrew does not drop privileges on installation you would be
giving all build scripts full access to your system.

~~~
nailer
I really like that message. It used to be something diffr\erent, which was
vague, but this actually tells you why it refuses to run as root.

------
lucideer
This is really horrific.

The idea that correctMkdir() exists at all seems to me to be so wrong-headed.

This comment from the source says a lot:

    
    
        // annoying humans and their expectations!
    

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.

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.

~~~
jergason
FWIW the comment you're calling out here is four years old:
[https://github.com/npm/npm/blame/d3095ff20b8ea01e7fbf93a4a69...](https://github.com/npm/npm/blame/d3095ff20b8ea01e7fbf93a4a697a04fea77d8e6/lib/config/core.js#L153),
before npm inc was formed.

The correctMkdir change seems more recent, but not really related to that
specific comment.

~~~
zdragnar
This could be my inner grumpy old man speaking, but as a general rule of
thumb, I look very poorly on editorializing in code comments. Originally
because I didn't want my junior devs embarrassing the company when our clients
received control of the code we wrote, but that also transferred into my
perception of open source.

That comment should not have survived 4 years. Again, inner grumpy old man
showing through.

Edit: to be clear, such comments are treated as reflective of the people and
organization behind them.

~~~
predakanga
I can see your point (particularly with regard to deliverables), but I suspect
the practice is quite widespread - comments often end up being used as a sort
of brain dump.

For instance, see this article (from 2004) on comments in the Win2k source
code:
[http://atdt.freeshell.org/k5/story_2004_2_15_71552_7795.html](http://atdt.freeshell.org/k5/story_2004_2_15_71552_7795.html)

~~~
zdragnar
That's a fair enough point, especially when directly employed working on
closed source / proprietary code. You're essentially stuck in an echo chamber,
and professional standards are more difficult to maintain when you don't have
the whole of the world looking on.

I also imagine that the mental strain of figuring out edge cases and poor
documentation in a system as complex as a windows OS would be enough to make
anyone at least a little salty.

However widespread it may be, that does not me that I have to like it :D

------
btown
There appear to be no unit tests for their entire lib/utils folder. Which
includes things like this (misguided) chown utility.
[https://github.com/npm/npm/tree/release-
next/test](https://github.com/npm/npm/tree/release-next/test) \- and note the
lack of testing in the commit linked in the bug report.

I had an inkling that NPM was cancer, but not like this.

Yarn, by contrast, has everything you would expect of a Facebook-engineered
library:
[https://github.com/yarnpkg/yarn/tree/master/__tests__/util](https://github.com/yarnpkg/yarn/tree/master/__tests__/util)

Will be closely evaluating a switch to Yarn for our live apps. This is simply
sad.

~~~
grahamj
"everything you would expect of a Facebook-engineered library"

So it collects your personal information, even when not using it, and uses it
for profit?

~~~
woah
I don’t like Facebook much, but their engineering is very good

~~~
whatever_dude
Only when your needs align with theirs. Which, truth be told, is fairly
common. But they have a tendency to ignore or give low priority to other
people's needs, like certain features that don't meet "Facebook scale" or,
just, documentation (see: Relay).

------
officialchicken
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.

Since I 'vote' with my code - this migration page has been helpful today - and
I hope it will help others: [https://yarnpkg.com/lang/en/docs/migrating-from-
npm/](https://yarnpkg.com/lang/en/docs/migrating-from-npm/)

It took me ~5 mins to migrate all of my code from npm to yarn. But I don't
have complex CI tasks either.

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?

[0]
[https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos)

[1]
[https://github.com/npm/registry/issues/255](https://github.com/npm/registry/issues/255)

*edit: formatting

~~~
explodingcamera
Github paths can change way more easily than npm packages, users can rewrite
git history + break your stuff and versioning when using it with npm is
horrible. NPM also now protects projects from namesquatting and prevents you
from deleting them when multiple projects depend on them.

~~~
kakarot
How does NPM protect from namesquatting now?

~~~
teamhappy
[http://blog.npmjs.org/post/168978377570/new-package-
moniker-...](http://blog.npmjs.org/post/168978377570/new-package-moniker-
rules)

------
jlgaddis
I just can't feel sorry for folks when I see comments like this one:

> _This destroyed 3 production server after a single deploy!_

I do think that the developers have a duty to do some testing of their
software before putting out releases/updates. However, _users_ also have a
duty to perform sufficient testing before they push new versions to their
production environments.

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 _next_ time it happens.

~~~
jguimont
I am the one who reported this ;) In fact that was a single production server
that I tried to reinstall 3 times before catching it was not really one of the
commits that was doing this. No data was lost or connectivity (as long as you
do not reboot it), you just lose any ssh connection/login.

Should I have done this on a staging server? Sure, but that does not change
the fact that I would have had to rebuild the whole server there too. It is
not expected that updating npm will kill the complete system it is on... It
would be expected to have some deploy failure of some sort.

As previously noted, `npm update -g npm` pulls in version 5.7.0. Version 5.6
is still the latest but for some obscure reason if you have thisupdate
anywhere in your deploy script you are screwed.

~~~
diggan
The real fix is to not run npm with sudo. Why would you do that in the first
place? npm runs install-scripts when you fetch packages, so you basically open
up root access for all the packages you download.

~~~
paulddraper
How is this different than running apt or yum or pacman or most other package
managers as sudo?

Somebody has to install system software.

~~~
diggan
npm is not for managing system software and has not been developed as such.
It's a javascript package manager. apt and pacman (and probably yum but never
used so can't speak about it) have active maintainers for most packages and
the mirrors are well taken care of.

npm is basically a giant array that anyone can add package to.

I'm using them both accordingly.

~~~
jguimont
I believe that node is installed with npm and both are installed in system
directories. I think they should by default point the npm global directory to
the user dir and not a system dir.

~~~
diggan
Depends on how you install them, think that's how the default install works
but nvm (which I use) puts everything under user directories. Agree with your
thinking though, should be changed in the default install for sure.

------
boffinism
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.'

Has this issue provoked so much outrage that GitHub can't handle the constant
stream of angry emojis on the issue comment thread?

~~~
kaiby
I had the same issue. Internet archive link:
[https://web.archive.org/web/20180222160101/https://github.co...](https://web.archive.org/web/20180222160101/https://github.com/npm/npm/issues/19883)

~~~
mkobit
I can't even get to that page as it times out as well.

EDIT: I opened the original link in incognito mode and the page seemed to load
fine.

------
foepys
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.

Everything is super dangerous as root, one should avoid using root at all
costs until there is no other way.

~~~
carussell
`sudo npm install -g` is one of several examples of the normalization of
deviance rife in the NodeJS community. Most command-line utilities distributed
through NPM recommend running as root (implicitly—because they all suggest
installing it as a global package). Here's[1] Microsoft's instructions to
install the TypeScript compiler, for example.

NPM's awfulness notwithstanding, it's trivial to write a shell script to do
what you say and add a symlink to ~/bin. But everyone on StackOverflow will
tell each other "just run it with sudo", and they do, and then quickly move on
with their lives (presumably to be followed with "and break things"). Instead
of doing the right thing, raising their hackles about how poorly NPM is
designed, and holding its community leaders accountable.

1\.
[https://github.com/Microsoft/TypeScript/blob/b29e0c9e3ab2471...](https://github.com/Microsoft/TypeScript/blob/b29e0c9e3ab247199eed6b69674a2c992c3a05a6/README.md#installing)

~~~
CJefferson
If I run npm without -g, it complains about missing files, and fills my home
directory with node_modules junk and a package-lock.json I have to "commit"?
Why do I want to commit it, and where?

I'm sure you are now going to tell me there is an easy way to fix that too,
and I'd be happy if there was, but for me I just want to use npm to install a
program or two.

~~~
plorkyeran
The correct way is to use `npm install -g --prefix` to install it into a
directory on your path which is writeable by your current user.

I don't think I've ever seen the install instructions for a npm-packaged tool
actually say to do this.

~~~
CJefferson
Thanks, I'll give that a try in future.

------
master-litty
[http://blog.npmjs.org/post/171169301000/v571](http://blog.npmjs.org/post/171169301000/v571)

    
    
      Thankfully, it only affected users running `npm@next`, which is part of our staggered release system
    
      #STOPUSINGPRERELEASEWITHSUDO
    

Really now?

    
    
      #ANGRYORANGEWEBSITE #PEOPLEGOTMAD
    

:)

~~~
enzanki_ars
This is just absolutely unprofessional.

All tags:

#ANGRYORANGEWEBSITE #PEOPLEGOTMAD #STOPUSINGPRERELEASESWITHSUDO #CLIHOTFIX
#WEGOTUBB #LITERALLYKILLEDGITHUB

Author:

FEBRUARY 22, 2018 (9:53 AM) @MAYBEKATZ

[https://web.archive.org/web/20180222201315/http://blog.npmjs...](https://web.archive.org/web/20180222201315/http://blog.npmjs.org/post/171169301000/v571)

------
mkj
Reminds me of a recent Yarn problem, overwriting which(1).
[https://github.com/yarnpkg/yarn/issues/4205](https://github.com/yarnpkg/yarn/issues/4205)

~~~
Silhouette
Both of these issues seem like a timely reminder that everyday Linux
desperately needs a proper application management and security model.

Installing software where your options are

1\. running as a regular user, and the install script can put whatever it
wants within your user's directories

or

2\. running as root, and the install script can do literally anything to
anywhere on your system

is not fit for purpose, when the risks from both malice and incompetence are
both reaching new heights almost daily.

These are systems we use for real work, but even smartphones and their toy app
stores do better now. How do we still not have controls so applications can
always be installed/uninstalled in a controlled way, can only access files and
other system resources that are relevant to their own operation, and so on?

~~~
vetinari
> everyday Linux desperately needs a proper application management

You mean something, that won't allow two packages to own the same file?
Something, like, rpm or apt?

~~~
y4mi
You probably meant rpm and dpkg... Or you'd have to compare yum, zypper, apt,
pacman and whatever else is out there.

But, I'm certain the parent didn't mean that. Dpkg and rpm both allow packages
to overwrite files from each other and, more dangerously, allow fully
authorized post-install scripts. And they're often necessary for sane package
management (create user, initiate database), but could be exploited to wreck
havoc on the system.

~~~
vetinari
Yes, I meant dpkg.

Not sure about dpkg, but rpm does not allow two packages to own the same file.
If you try to install package, that contains file owned by another, already
installed package, the installation will fail (you can try that with
installing an amd64 package that owns something in /usr/share, and then try to
install the i386 version). Yes, post-install scripts are dangerous and rpm
folks are doing small steps to phase them out:
[https://www.youtube.com/watch?v=kE-8ZRISFqA](https://www.youtube.com/watch?v=kE-8ZRISFqA)

~~~
Piskvorrr
dpkg will throw a fit in the same way.

~~~
y4mi
it will throw an error message, which the user is probably going to ignore and
install anyway.

This will ultimately cause errors down the line. Maybe not right now, but
eventually problems will occur.

showing a warning is great, but not needing that warning would be preferable.

but most distributions are already working on solutions to that. ubuntu is
working on SnapOn's [0] for example, and i remember hearing about something
else from redhad as well.

[0] [https://snapcraft.io/](https://snapcraft.io/)

~~~
__david__
No, it will not install the package at all:

    
    
        $ mkdir root/bin/
        $ (echo '#!/bin/sh'; echo 'echo "hi"') > root/bin/ls
        $ chmod +x root/bin/ls
        $ fpm -s dir -t deb -n bad-ls -v 1.0 -C `pwd`/root .
        Created package {:path=>"bad-ls_1.0_amd64.deb"}
        $ dpkg-deb -c bad-ls_1.0_amd64.deb
        drwxrwxr-x 0/0               0 2018-02-22 10:44 ./
        drwxr-xr-x 0/0               0 2018-02-22 10:44 ./usr/
        drwxr-xr-x 0/0               0 2018-02-22 10:44 ./usr/share/
        drwxr-xr-x 0/0               0 2018-02-22 10:44 ./usr/share/doc/
        drwxr-xr-x 0/0               0 2018-02-22 10:44 ./usr/share/doc/bad-ls/
        -rw-r--r-- 0/0             142 2018-02-22 10:44 ./usr/share/doc/bad-ls/changelog.gz
        drwxrwxr-x 0/0               0 2018-02-22 10:44 ./bin/
        -rwxrwxr-x 0/0              20 2018-02-22 10:42 ./bin/ls
        $ sudo dpkg -i bad-ls_1.0_amd64.deb
        Selecting previously unselected package bad-ls.
        (Reading database ... 837129 files and directories currently installed.)
        Preparing to unpack bad-ls_1.0_amd64.deb ...
        Unpacking bad-ls (1.0) ...
        dpkg: error processing archive bad-ls_1.0_amd64.deb (--install):
         trying to overwrite '/bin/ls', which is also in package coreutils 8.28-1
        Errors were encountered while processing:
         bad-ls_1.0_amd64.deb
        $ ls -l /bin/ls
        -rwxr-xr-x 1 root root 134792 Oct  2 10:51 /bin/ls*
    

It doesn't just warn and leave things in a bad state.

~~~
y4mi
this is strange. I encountered a conflict at work recently with an /etc/ file
conflict.

the stdout of the dpkg errormsg gave me the required tag i could use to do it
anyway. it was basically just

    
    
      !! double click -> middle click

------
hysan
Doesn't really surprise me when you have other issues like this
([https://github.com/npm/npm/issues/17929](https://github.com/npm/npm/issues/17929))
that have persisted for a long time. NPM 5.x in general hasn't been very
stable.

~~~
Silhouette
_NPM 5.x in general hasn 't been very stable._

Indeed. Another odd thing that it's been doing lately is when I run some NPM
scripts on one of our machines, it starts shouting about some sort of update
not working (why was it updating anything at all just because I ran `npm run
something`?) and gives me instructions on how to fix it from the Linux shell
(on a Windows box). The depth of failure implied by that message is disturbing
on several levels.

------
nwhatt
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.

------
akras14
Wayback link, of someone has a better mirror please post:
[http://web.archive.org/web/20180222170341/https://github.com...](http://web.archive.org/web/20180222170341/https://github.com/npm/npm/issues/19883)

------
InclinedPlane
From:
[https://github.com/npm/npm/releases/tag/v5.7.1](https://github.com/npm/npm/releases/tag/v5.7.1)

 _" 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!"_

If you are updating to the latest pre-release of something within mere _hours_
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.

------
RX14
My personal opinion is that the root cause of the issue is the ability of a
_language_ 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.

I wrote about this in longer form here: [https://github.com/crystal-
lang/crystal/pull/3328#issuecomme...](https://github.com/crystal-
lang/crystal/pull/3328#issuecomment-247970222).

------
ishanjain28
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.

------
dictum
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:

[http://appleinsider.com/articles/09/10/12/snow_leopard_guest...](http://appleinsider.com/articles/09/10/12/snow_leopard_guest_account_bug_deletes_user_data)

(Yeah, it's _that_ much-vaunted Snow Leopard.)

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.

------
jehlakj
Why do people feel the need to update especially on production servers?
Shouldn’t production servers be updated only when necessary?

~~~
igotsideas
Good question. You would think that some people would have QA/pre-prod servers
with a pipeline that would catch this.

------
obw
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?

~~~
Piskvorrr
And even worse, 5.6.0 to 5.7.0 is, by semver, one minor point release to
another minor point release - no breaking changes, no major bugs. 5.7.0-pre
would raise some flags.

~~~
floatboth
Uhh. Does semver actually say anything about _bugs_?! o_0

~~~
romanovcode
I'm pretty sure you don't release pre-release versions without -pre or -beta
or -rc tags in the end.

~~~
dan15
Technically you don't _have_ to with semver, it's just a good practice. From
[https://semver.org/](https://semver.org/):

> A pre-release version MAY be denoted by appending a hyphen and a series of
> dot separated identifiers immediately following the patch version.

Note that it says "MAY" and not "MUST", so it's optional.

------
dlandis
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.

~~~
matharmin
Yarn is actually a very good alternative to the NPM cli. While there has been
some issues on the package hosting side as well, by far the biggest issues
were/are on the client side, and practically a of them are solved by Yarn.

------
whatever_dude
I swear NPM has some absurd showstopping bug every month.

With something that has as many people using it, it's just... I dunno, it's
disheartening.

Edit: oh well, this was a @next release only. Not as bad. Still scary.

------
homulilly
I really wish node would ship with Yarn instead of NPM. Every serious js
project these days already uses it.

~~~
my_ghola
Does yarn run npm behind the scenes? Or does it even replicate the bugs in its
attempt to be fully compatible? I used yarn to install global packages and see
the packages in `/usr/lib/node_modules` with the permissions of my user rather
than root.

~~~
tuananh
yarn use npm registry behind the scene.

------
coreycoto
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.

That is a recipe for disaster.

------
erulabs
Looks at correct-mkdir. Sees "cb = dezalgo(cb)".
[https://www.npmjs.com/package/dezalgo](https://www.npmjs.com/package/dezalgo)

"Contain async insanity so that the dark pony lord doesn't eat souls"

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 [https://blog.ometer.com/2011/07/24/callbacks-synchronous-
and...](https://blog.ometer.com/2011/07/24/callbacks-synchronous-and-
asynchronous/) 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...

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?

"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."

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:

"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."

So it's slower -and- more complicated, and we're gonna hide it behind a meme.
Gotcha.

~~~
fenwick67
Deferring until next tick is one way to get around call stack problems. If you
create a really big series of callbacks which will call other callbacks which
call other callbacks... you can run out of call stack.

The other issue is let's say you have some code like...

    
    
        var f = 1
        doSomeOperation(function done(){
            console.log(f)
        })
        f = 5
    

If doSomeOperation calls done() sometimes syncronously and sometimes
asynchronously, it will sometimes log 1 and sometimes log 5. If
doSomeOperation always works one way it's more consistent. It's not a perf
thing it's just consistency.

------
_Chief
I wish fixing of npm global directory permissions was part of the npm install
page ([https://docs.npmjs.com/getting-started/installing-
node](https://docs.npmjs.com/getting-started/installing-node)), 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.

------
ashtonian
[https://www.dayssincenpmbroke.com/](https://www.dayssincenpmbroke.com/)

accepting PRs:
[https://github.com/Ashtonian/dayssincenpmbroke.com](https://github.com/Ashtonian/dayssincenpmbroke.com)

~~~
rootlocus
Do you really need google analytics for this?

~~~
ashtonian
need is a strong word. Do I need the entire site - no. The mentality was more
like "oh haha joke site?.... I wonder how many people are actually looking at
the site and from where.. man I wonder if there is a solution for that... oh
right google analytics."

~~~
rootlocus
> I wonder how mwany people are actually looking at the site and from where..
> man I wonder if there is a solution for that... oh right google analytics.

And I wonder if it's possible to make a 2 dollar website without tracking your
users or reporting to google.

I expect most people who dabble with technology use an adblocker anyway which
blocks requests to google analytics.

I wouldn't mind a self hosted analytics solution, but with all the captchas
and the mails, I feel we give google enough information as it is.

~~~
ashtonian
wellllllllll when you make a website as a joke you can choose which if any
analytics solution you want. And deal with the critics that use analytic
blockers to complain about your analytics solution.

The site collected 10k visits over 3 days from around the world.

------
x2e2l2a
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.

------
kuon
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.

~~~
homulilly
It's bad, but at the same time it's hard to blame people doing it too much
when it's literally in the npm documentation:
[https://docs.npmjs.com/troubleshooting/common-
errors](https://docs.npmjs.com/troubleshooting/common-errors)

~~~
kuon
I am not blaming people, maybe my comment wasn't formulated properly. What I
meant is "don't do it, there is an alternative".

I think no documentation should ever include sudo in their commands. You
should put a note "depending on your environment, some of those commands might
require root privileges" or something.

------
Sujan
Reading this and the comments here really makes me feel sorry for the npm
people.

If you are reading this: You are doing great work, I wish you the energy and
strength to ignore the trolls.

------
tuananh
Switching to yarn is not going to fix this. However, this raise some concern
about npm cli

\- we are relying on 2 people team for our applications. \- maintainer doesn't
seem to care much about this horrific bug:
[https://imgur.com/a/v4Ndb](https://imgur.com/a/v4Ndb)

~~~
rk06
> Switching to yarn is not going to fix this.

Yeah, but if you had switched to yarn beforehand, then you would not be facing
this issue.

~~~
tuananh
iirc yarn has a bug regarding `which` cli which is similar to this.

bugs are bound to happen and it's part of software development. however, the
team size of npm cli and the way they react to this incident are what make me
concern more.

------
johnvega
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.

------
jxkcicickgkicu
Why would reporter run sudo npm???

~~~
45h34jh53k4j
sudo yum sudo apt-get sudo pacman

Why wouldn't you naively assume sudo npm was safe if you wanted a global
package (I know the behavior of npm...)

This is blaming the victims. If the user can blow their foot off, its not the
users fault.

------
Sujan
Title should be changed to 5.7.0 as newly released 5.7.1 fixes the bug.

~~~
Nadya
Maturely tagged with `#STOPUSINGPRERELEASESWITHSUDO`

When their Official Blog makes no mention of 5.7.0 being a prelease [0] and is
semantically versioned as a stable release. The thread also later details that
running `npm upgrade -g npm` instead of `npm install -g npm`will get 5.7.0
instead of 5.6.0 [1].

Is it standard practice for an `upgrade` command to pull a pre-release or
beta? When I upgrade Firefox I don't get put onto the Nightly branch...

[0] [https://vgy.me/LkvBKS.png](https://vgy.me/LkvBKS.png)

[1]
[https://github.com/npm/npm/issues/19883#issuecomment-3677268...](https://github.com/npm/npm/issues/19883#issuecomment-367726819)

~~~
Sujan
This is relevant to the information I posted in my comment here how?

It is not.

------
my_ghola
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?

------
atilkan
Destroyed my local packages. Can't resist to yarn anymore. Switched.

------
digi_owl
Remind me again why there are language specific package managers...

