I experienced similar chaos after updating to 5.7.0 in a FreeBSD jail, I noticed recursive ownership of at least /usr/local/etc had been given to the current user:group during the update (npm update -g). Thankfully I could rollback to a snapshot of my filesystem from before the update and 5.6.0 works fine again.

As a precaution against potentially catastrophic effects, I hope 5.7.0 will be taken down while a fix is implemented.

This destroyed 3 production server after a single deploy!

Same in a docker as root, some command like npm config set registry complained about EACCESS error on /root dir oO error code return is 7

All worked fine with 5.6 :(

I experienced similar issue.
I'm using AWS ec2 (Amazon Linux AMI 2017.09.1 (HVM), SSD Volume Type - ami-f2d3638a).
It's clean environment. (Nothing installed.)

After npm v5.7.0 installed, /usr/bin's execution files ownership is updated to ec2-user:ec2-user from root:root. After the update, I cannot do sudo, so I need to re-create EC2 instance.

Here is the commands that reproduces the situation:

on ~ec2-user directory,

ls -l /usr/bin
# you can see correct ownership

sudo su
curl --silent --location https://rpm.nodesource.com/setup_6.x | bash -
exit

sudo yum update
sudo yum install git
sudo yum install nodejs
git clone https://github.com/isaacs/npm.git
cd npm
git checkout v5.7.0
make
sudo make install

ls -l /usr/bin
# you can see broken ownership

Why are you using a pre-release version in production @juggy? Just asking...

Tag doesn't look like pre-release until you actually click on the releases and check the tag. If it's a pre-release tag, I suggest to not format the tag in a way it looks like it could not be a pre-release tag.

I suggest to do no publish pre-release version announcement on the official blog: http://blog.npmjs.org/post/171139955345/v570

I suggest to do no publish pre-release version announcement on the official blog: http://blog.npmjs.org/post/171139955345/v570

...which doesn't mention it's a pre-release in any way, shape or form.

Pre-releases is alpha, beta, rc, pre, etc. …

5.7.0 looks like minor stable release.

lol

Sorry people, wasn’t meant to be rude 🙄

npm 5.7.0 on Mac not worked

@towc welp, missed that 🆗

haha )) can someone prove that this update does destroy production servers ?

Oh yes

Doc link
https://docs.npmjs.com/getting-started/fixing-npm-permissions

Mind staying on topic, rather than enforcing your opinion on us for an unrelated subject? Thanks!

I think it would be preferable to only explicitly set permissions on folders that actually will be created by npm instead of just tinkering with the existing folders, especially when that code is accessing critical folders as the root user (through sudo). In the worst case, this renders systems unbootable and/or unusable.

On another note, it is indeed confusing to just use v5.7.0 as a pre-release version name despite the pre-release marker on GitHub. Or is the routine to mark upcoming releases as pre-releases and then just switching them over to stable release as-is?

🍿

consider reading this

Playing a dangerous game by doing a minor stable release that's actually a pre.

Things like this are like a 🍆 in the face of npm and node. And I love it.

For the people asking "why is 5.7.0 a prerelease released as stable", it's not:

{ latest: '5.6.0',
     next: '5.7.0'

It's tagged as next, so if you got it you either explicitly installed that version knowing it's marked as next, or you installed @next.

Release channels exist for a reason. If you're running "next" on production environments you're asking for trouble.

If what he's saying is correct, the pre-release appears to be pushed to the Arch main repositories, so if you're on Arch, beware! I've uninstalled npm and nodejs from my Arch box for the moment just to prevent any extra fun until this bug is fixed.

EDIT: it appears I misread his steps to recreate. Updating npm from npm is what installed the 5.7.0 version. Still bad, but not related to Arch's repositories.

@trodrigues might be still worth writing about this more explicitly on the blog post. Nobody coming to the site would know from reading it that it's a pre-release at the time.

Edit: for clarity, I'm referring to this: http://blog.npmjs.org/post/171139955345/v570

I ran npm update -g this morning and my local npm 5.6.0 was upgraded to 5.7.0 so in some way, it must have gone beyond a pre-release.

Generally in projects that follow semver I expect pre-release packages to have some string suffixed to the version number such as 5.7.0-next.

This is only listed as a MAY in the spec but it does allow you to immediately tell if a release is considered stable or not just from the version number.

If what he's saying is correct, the pre-release appears to be pushed to the Arch main repositories, so if you're on Arch, beware!

I don't know where you see that, but it's not the case.

has anyone an idea how to test the fix and makes sure, that this kind of issue doesn't come up again in the future?

Yup. It's really easy. Don't do stupid things like messing with directories and files that are not yours.

This is a serious and problematic issue. However if you are running versions of critical software, like NPM, in production only hours after it's released you should probably reconsider your deployment procedures. Using the NPM versions tied to the LTS version of Node.js, which you should be using, is plenty greenfield enough.

This is quite correct. It's easy and understandable to miss, but if you have this in your deployment process somewhere:

npm install -g npm

be more specific about the versioning:

npm install -g npm@5.6.0

It's similar to using the latest tag on Docker images, or gem install bundler, or accepting any default definition of "give me the latest version". Lock your versions at every step of the process. Be defensive about your deploy process. 👍

Just got the latest Node Weekly, whose first item is:

npm v5.7.0 Releasedn
pm install can now automatically fix package-lock.json and npm-shrinkwrap.jsonfiles that have merge conflicts, there’s also a new npm ci command.

Just so you know.

@k0nserv Still you can really mess up your dev machine. Things like this should never, ever happen. And they're happening a little too often to Node 😒

I'm not heavily invested in this issue, but if you want this thread to feature more rational discussion, tweeting about it is probably a bad idea.

I almost hate to contribute to this, but a hopefully informative bit of information:

This issue is made worse by the version tagging

latest: 5.6.0
next: 5.7.0

because npm upgrade does not take that into account and will pull the newest version (5.7.0).

Because of this, you should not npm upgrade -g npm or else you will get these pre-release builds. npm itself will tell you to run npm install -g npm isntead, which does pull latest and ignore that next is newer:

~ 🐒   npm -v
5.5.1


   ╭─────────────────────────────────────╮
   │                                     │
   │   Update available 5.5.1 → 5.6.0    │
   │     Run npm i -g npm to update      │
   │                                     │
   ╰─────────────────────────────────────╯

~ 🐒   npm i -g npm
+ npm@5.6.0
added 27 packages, removed 11 packages and updated 38 packages in 7.544s

~ 🐒   npm -v
5.6.0

~ 🐒   npm upgrade -g npm
+ npm@5.7.0
added 63 packages, removed 6 packages and updated 49 packages in 8.432s

~ 🐒   npm -v
5.7.0

so you can protect yourself from inadvertently getting these pre-release builds into our production environments by sticking to npm i -g.

I'm not heavily invested in this issue, but if you want this thread to feature more rational discussion, tweeting about it is probably a bad idea.

Maybe this helps to dismantle the js bloat ecosystem which is slowly making the internet unusable.

Its always nasty to have such problems. Besides all the talk/memes/etc., has anyone an idea how to test the fix and makes sure, that this kind of issue doesn't come up again in the future?

Yes, run it in a CI environment set up with selinux or apparmor configured to deny npm any action outside of its own work area. If it runs and doesn't break, chances are it won't corrupt the system. Maybe itself, but at least not the system.

@k0nserv Still you can really mess up your dev machine. Things like this should never, ever happen. And they're happening a little to often to Node. :(

You should be running the same versions of NPM/Node.js in dev as production so this is a non problem. The current LTS is 8.9.4 it comes with NPM 5.6.0. Just stay on a recent LTS release and use the NPM versions bundled with it.

1. Be a dev on one of the most critical pieces of on infrastructure of a widely used language.
2. Release new prerelease.
3. Do not use semantic versioning so it looks like a stable.
4. Advertise new build in emails and blog posts but don't mention it's a prerelease.
5. The update mechanism updates to next instead of latest for whatever reason
6. It bricks everyone's systems.
7. Users are reasonably upset.
8. Insult users for being upset.

It might be time for an expansion of the NPM team and a review of the current developers on it.

Thank you to everyone who is ranting about us posting immature bullshit on this bug report. I now have a nice neat list of assholes I would never hire.

How about we give the two person team more than 24 hours to run npm unpublish npm@5.7.0 ?

How about we give the two person team more than 24 hours to run npm unpublish npm@5.7.0

I'm not sure if you're joking, but that command only allows unpublishing versions published within 24 hours, and not older.

That's okay, it was tagged 19 hours ago...

FYI: npm@5.7.1 got released a few hours ago and resolves this issue. 5.7.0 will promptly fade into oblivion :) Cheers.

Looking back at my reaction this week, I realize that in the moment my responses were inappropriate and I have decided to delete the comment. Obviously, hiring decisions for any organization that I work for are based on wider evaluations of each individual’s background and qualifications. To anyone I may have offended, please accept my sincere apologies.