19 ms·

Do not use NPM 5.7

544 points by jguimont 9y ago

obw 9y ago
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 9y ago
  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 9y ago
    Uhh. Does semver actually say anything about bugs?! o_0
    - romanovcode 9y ago
      I'm pretty sure you don't release pre-release versions without -pre or -beta or -rc tags in the end.
      - dan15 9y ago
        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.
    - Piskvorrr 9y ago
      I'm pretty sure that "we're now changing permissions willy-nilly" is both a breaking change (which would warrant a major version bump, as per semver), and a bug (even though it's presented as an improvement by the authors). I should have been more clear.
- seba_dos1 9y ago
  What's more, while "npm install -g npm" correctly installs 5.6.0, "npm update -g npm" installs this apparently pre-release 5.7.0 version.
zaarn 9y ago
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-mkdir.js#L54 https://github.com/npm/npm/blob/latest/lib/utils/correct-mkd... ] 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 9y ago
  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/
  - zaarn 9y ago
    I think the easy solution here would be to disable global installs. Pip does that same stuff and it also is known to get people's computers into quite advanced states. Ideally npm should simply setup a dedicated directory in /opt or /usr/local/ (ie, /usr/local/node/bin or /opt/node/bin) in which it dumps all the global stuff. That way you can easily set permissions for a user and/or contain any damages to that folder. If npm blows up that way it doesn't murder the entire system, you'll still be able to SSH in. (That is unless you use a SSH agent based on node.js in which case; "why?") Once npm has implemented such a location it should refuse to run with sudo and demand the user setup the correct permissions within the node folder (maybe setup a group "npm-manage" during install?)
    - diggan 9y ago
      > easy solution here would be to disable global installs I think that's not optimal. Having package being installed "globally" (as in available on your PATH) is nice. You can install `yarn` by doing `npm install --global yarn`. The trouble is how people setup their node/npm installation. Instead of having global packages setup under the home directory, people use the default which requires root access. Instead, default installation should be in user-accessible place and running npm with sudo should be exiting without doing anything.
lucideer 9y ago
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 9y ago
  FWIW the comment you're calling out here is four years old: https://github.com/npm/npm/blame/d3095ff20b8ea01e7fbf93a4a697a04fea77d8e6/lib/config/core.js#L153 https://github.com/npm/npm/blame/d3095ff20b8ea01e7fbf93a4a69..., before npm inc was formed. The correctMkdir change seems more recent, but not really related to that specific comment.
  - zdragnar 9y ago
    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.
    - lucideer 9y ago
      I think there should definitely be limits to this—some brevity/levity can be positive—so I would always try to err on the side of acceptance, but in general I agree. In this particular case at least, this comment seems to betray some hint of an anti-user sentiment.
btown 9y ago
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 9y ago
  "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?
  - btown 9y ago
    At the risk of troll-engaging: there's a huge difference between using an independently-auditable, multiple-contributing-entity, open-source library that happens to have been originated by a social network's engineering team, and using the identity-tracking public APIs of a closed social network. And both can be useful in certain situations. Be wary, but don't close oneself off to good technology just because it's associated with technology you disapprove of.
    - fenwick67 9y ago
      You are right that their OSS doesn't spy on you, but... > don't close oneself off to good technology just because it's associated with technology you disapprove of I disagree, if you think Facebook is evil, don't use their libraries. Using them gives Facebook positive publicity and good will.
      - austinshea 9y ago
        OSS can of course spy on you. You just have a reasonable way to audit that software, and find that out for yourself. If you can audit it yourself, why not use it? I won't follow you on your quest to rid yourself of things created by corporations that I find to be evil. It's your opinion, sure, but using a corporation's tech does not ensure positive publicity or good will.
mkj 9y ago
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 9y ago
  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?
  - Piskvorrr 9y ago
    FWIW, "new npm broke Æeeeverything? Meh. Destroy the docker container, force version <= 5.6.0, rebuild" has now saved me from a bigger disaster. This is the 1.5th option, IMNSHO: npm gets its root(-ish) access, host computer is somewhat protected.
  - progval 9y ago
    > everyday Linux desperately needs a proper application management and security model. We already have the necessary tools to do it, eg. firejail. We only have to make every binary run in firejail by default (and write firejail profiles for more binaries).
  - mastax 9y ago
    Yeah people like to hate on Microsoft/Mac App Stores, but at least they don't let programs vomit files across the disk. The Linux solution I suppose is Nix/Guix or Flatpak/Snap or Docker a la RancherOS. Perhaps more restrictive SELinix profiles could work as well.
dictum 9y ago
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_account_bug_deletes_user_data http://appleinsider.com/articles/09/10/12/snow_leopard_guest... (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.
ishanjain28 9y ago
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.
deleted 9y ago
[deleted]
hysan 9y ago
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 9y ago
  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.
boffinism 9y ago
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 9y ago
  I had the same issue. Internet archive link: https://web.archive.org/web/20180222160101/https://github.com/npm/npm/issues/19883 https://web.archive.org/web/20180222160101/https://github.co...
  - mkobit 9y ago
    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.
- fokinsean 9y ago
  Yeah that entire thread is a dumpster fire.
- jlgaddis 9y ago
  Log out of Github and then reload the page. WFM.
  - code_duck 9y ago
    Does not work for me and I am not logged into github.
- SilasX 9y ago
  Maybe Github was deploying with npm.
foepys 9y ago
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.
- tbranyen 9y ago
  Because sometimes you are writing software that interacts with hardware at a root level. This is really annoying advice you're giving since its absolute and without context. No, not everything is "super dangerous" with sudo. Get that FUD outta here!
  - diggan 9y ago
    npm should never interact with hardware, it's job is to install and manage packages. I could understand that you have to run nodejs with root, since it actually can use the hardware. But using npm with root user? I can't think of a single usecase.
    - tbranyen 9y ago
      Well think harder. Npm runs scripts from package.json. Most folks wouldn't think twice to run sudo npm start as a replacement for sudo node. I sure wouldn't think npm would start mucking with file permissions.
      - diggan 9y ago
        I'm sorry but that people can't figure out where to put `sudo` is not a usecase for using sudo... Instead of running `sudo npm start`, have `scripts.start` have the value `sudo node index.js` if you want. But then again, I'm not "most folks", I try to think when I am the root user and don't run third-party code willy-nilly when I am.
    - chopin 9y ago
      I am not a node guy but as far as I understand nodejs is a webserver, no? _Never_ run any webserver as root. This is just bad practice.
jlgaddis 9y ago
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 9y ago
  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 9y ago
    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.
    - breatheoften 9y ago
      This 1000 times. Running npm as sudo is a terrible terrible idea. I remember creating a slack channel in our team called 'never run npm with sudo' and ranting in dramatic fashion to try and overcome the effect of the printed advice which npm used to output in most failure situations to 'try re-running the command with sudo.' This tended to cause developers new to the ecosystem to re-run the command with sudo and create lots of problems for themselves -- in addition to being an extremely bad security practice. Honestly -- I think npm should be updated to exit without doing anything if it detects its run with root privileges ...
deleted 9y ago
[deleted]
nwhatt 9y ago
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.
dlandis 9y ago
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 9y ago
  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.
master-litty 9y ago
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 :)
- homulilly 9y ago
  I guess they're just refusing to acknowledge that upgrading npm installed the "prerelease" version?
- enzanki_ars 9y ago
  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.org/post/171169301000/v571 https://web.archive.org/web/20180222201315/http://blog.npmjs...
kuon 9y ago
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 9y ago
  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 9y ago
    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.
jehlakj 9y ago
Why do people feel the need to update especially on production servers? Shouldn’t production servers be updated only when necessary?
- igotsideas 9y ago
  Good question. You would think that some people would have QA/pre-prod servers with a pipeline that would catch this.
RX14 9y ago
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#issuecomment-247970222 https://github.com/crystal-lang/crystal/pull/3328#issuecomme....
digi_owl 9y ago
Remind me again why there are language specific package managers...
jxkcicickgkicu 9y ago
Why would reporter run sudo npm???
- 45h34jh53k4j 9y ago
  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.
coreycoto 9y ago
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.
Sujan 9y ago
Title should be changed to 5.7.0 as newly released 5.7.1 fixes the bug.
- jt2190 9y ago
  http://blog.npmjs.org/post/171169301000/v571 http://blog.npmjs.org/post/171169301000/v571
- Nadya 9y ago
  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-367726819 https://github.com/npm/npm/issues/19883#issuecomment-3677268...
  - Sujan 9y ago
    This is relevant to the information I posted in my comment here how? It is not.
Sujan 9y ago
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.
akras14 9y ago
Wayback link, of someone has a better mirror please post: http://web.archive.org/web/20180222170341/https://github.com/npm/npm/issues/19883 http://web.archive.org/web/20180222170341/https://github.com...
_Chief 9y ago
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.
homulilly 9y ago
I really wish node would ship with Yarn instead of NPM. Every serious js project these days already uses it.
- my_ghola 9y ago
  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 9y ago
    yarn use npm registry behind the scene.
InclinedPlane 9y ago
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.
officialchicken 9y ago
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 9y ago
  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 9y ago
    How does NPM protect from namesquatting now?
    - teamhappy 9y ago
      http://blog.npmjs.org/post/168978377570/new-package-moniker-rules http://blog.npmjs.org/post/168978377570/new-package-moniker-...
- TAForObvReasons 9y ago
  The left-pad debacle was a registry issue but the current issue is an npm client issue. In my experience, NPM 5 client versions have been shaky and unreliable, and there are problems with popular ecosystems like react-native [0]. I always roll back to npm 4, even on node 9. [0] https://github.com/facebook/react-native/issues/14209 https://github.com/facebook/react-native/issues/14209
ashtonian 9y ago
https://www.dayssincenpmbroke.com/ https://www.dayssincenpmbroke.com/ accepting PRs: https://github.com/Ashtonian/dayssincenpmbroke.com https://github.com/Ashtonian/dayssincenpmbroke.com
- rootlocus 9y ago
  Do you really need google analytics for this?
  - ashtonian 9y ago
    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 9y ago
      > 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 9y ago
        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.
my_ghola 9y ago
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?
whatever_dude 9y ago
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.
johnvega 9y ago
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.
tuananh 9y ago
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 9y ago
  > 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 9y ago
    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.
erulabs 9y ago
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-asynchronous/ https://blog.ometer.com/2011/07/24/callbacks-synchronous-and... 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 9y ago
  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.
x2e2l2a 9y ago
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.
atilkan 9y ago
Destroyed my local packages. Can't resist to yarn anymore. Switched.

544 points by jguimont 9y ago

obw 9y ago

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 9y ago
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 9y ago
  Uhh. Does semver actually say anything about bugs?! o_0
  - romanovcode 9y ago
    I'm pretty sure you don't release pre-release versions without -pre or -beta or -rc tags in the end.
    - dan15 9y ago
      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.
  - Piskvorrr 9y ago
    I'm pretty sure that "we're now changing permissions willy-nilly" is both a breaking change (which would warrant a major version bump, as per semver), and a bug (even though it's presented as an improvement by the authors). I should have been more clear.
seba_dos1 9y ago
What's more, while "npm install -g npm" correctly installs 5.6.0, "npm update -g npm" installs this apparently pre-release 5.7.0 version.

zaarn 9y ago

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-mkdir.js#L54 https://github.com/npm/npm/blob/latest/lib/utils/correct-mkd... ] 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 9y ago
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/
- zaarn 9y ago
  I think the easy solution here would be to disable global installs. Pip does that same stuff and it also is known to get people's computers into quite advanced states. Ideally npm should simply setup a dedicated directory in /opt or /usr/local/ (ie, /usr/local/node/bin or /opt/node/bin) in which it dumps all the global stuff. That way you can easily set permissions for a user and/or contain any damages to that folder. If npm blows up that way it doesn't murder the entire system, you'll still be able to SSH in. (That is unless you use a SSH agent based on node.js in which case; "why?") Once npm has implemented such a location it should refuse to run with sudo and demand the user setup the correct permissions within the node folder (maybe setup a group "npm-manage" during install?)
  - diggan 9y ago
    > easy solution here would be to disable global installs I think that's not optimal. Having package being installed "globally" (as in available on your PATH) is nice. You can install `yarn` by doing `npm install --global yarn`. The trouble is how people setup their node/npm installation. Instead of having global packages setup under the home directory, people use the default which requires root access. Instead, default installation should be in user-accessible place and running npm with sudo should be exiting without doing anything.

lucideer 9y ago

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 9y ago
FWIW the comment you're calling out here is four years old: https://github.com/npm/npm/blame/d3095ff20b8ea01e7fbf93a4a697a04fea77d8e6/lib/config/core.js#L153 https://github.com/npm/npm/blame/d3095ff20b8ea01e7fbf93a4a69..., before npm inc was formed. The correctMkdir change seems more recent, but not really related to that specific comment.
- zdragnar 9y ago
  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.
  - lucideer 9y ago
    I think there should definitely be limits to this—some brevity/levity can be positive—so I would always try to err on the side of acceptance, but in general I agree. In this particular case at least, this comment seems to betray some hint of an anti-user sentiment.

btown 9y ago

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 9y ago
"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?
- btown 9y ago
  At the risk of troll-engaging: there's a huge difference between using an independently-auditable, multiple-contributing-entity, open-source library that happens to have been originated by a social network's engineering team, and using the identity-tracking public APIs of a closed social network. And both can be useful in certain situations. Be wary, but don't close oneself off to good technology just because it's associated with technology you disapprove of.
  - fenwick67 9y ago
    You are right that their OSS doesn't spy on you, but... > don't close oneself off to good technology just because it's associated with technology you disapprove of I disagree, if you think Facebook is evil, don't use their libraries. Using them gives Facebook positive publicity and good will.
    - austinshea 9y ago
      OSS can of course spy on you. You just have a reasonable way to audit that software, and find that out for yourself. If you can audit it yourself, why not use it? I won't follow you on your quest to rid yourself of things created by corporations that I find to be evil. It's your opinion, sure, but using a corporation's tech does not ensure positive publicity or good will.

mkj 9y ago

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 9y ago
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?
- Piskvorrr 9y ago
  FWIW, "new npm broke Æeeeverything? Meh. Destroy the docker container, force version <= 5.6.0, rebuild" has now saved me from a bigger disaster. This is the 1.5th option, IMNSHO: npm gets its root(-ish) access, host computer is somewhat protected.
- progval 9y ago
  > everyday Linux desperately needs a proper application management and security model. We already have the necessary tools to do it, eg. firejail. We only have to make every binary run in firejail by default (and write firejail profiles for more binaries).
- mastax 9y ago
  Yeah people like to hate on Microsoft/Mac App Stores, but at least they don't let programs vomit files across the disk. The Linux solution I suppose is Nix/Guix or Flatpak/Snap or Docker a la RancherOS. Perhaps more restrictive SELinix profiles could work as well.

dictum 9y ago

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_account_bug_deletes_user_data http://appleinsider.com/articles/09/10/12/snow_leopard_guest... (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.

ishanjain28 9y ago

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.

deleted 9y ago

[deleted]

hysan 9y ago

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 9y ago
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.

boffinism 9y ago

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 9y ago
I had the same issue. Internet archive link: https://web.archive.org/web/20180222160101/https://github.com/npm/npm/issues/19883 https://web.archive.org/web/20180222160101/https://github.co...
- mkobit 9y ago
  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.
fokinsean 9y ago
Yeah that entire thread is a dumpster fire.
jlgaddis 9y ago
Log out of Github and then reload the page. WFM.
- code_duck 9y ago
  Does not work for me and I am not logged into github.
SilasX 9y ago
Maybe Github was deploying with npm.

foepys 9y ago

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.

tbranyen 9y ago
Because sometimes you are writing software that interacts with hardware at a root level. This is really annoying advice you're giving since its absolute and without context. No, not everything is "super dangerous" with sudo. Get that FUD outta here!
- diggan 9y ago
  npm should never interact with hardware, it's job is to install and manage packages. I could understand that you have to run nodejs with root, since it actually can use the hardware. But using npm with root user? I can't think of a single usecase.
  - tbranyen 9y ago
    Well think harder. Npm runs scripts from package.json. Most folks wouldn't think twice to run sudo npm start as a replacement for sudo node. I sure wouldn't think npm would start mucking with file permissions.
    - diggan 9y ago
      I'm sorry but that people can't figure out where to put `sudo` is not a usecase for using sudo... Instead of running `sudo npm start`, have `scripts.start` have the value `sudo node index.js` if you want. But then again, I'm not "most folks", I try to think when I am the root user and don't run third-party code willy-nilly when I am.
  - chopin 9y ago
    I am not a node guy but as far as I understand nodejs is a webserver, no? _Never_ run any webserver as root. This is just bad practice.

jlgaddis 9y ago

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 9y ago
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 9y ago
  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.
  - breatheoften 9y ago
    This 1000 times. Running npm as sudo is a terrible terrible idea. I remember creating a slack channel in our team called 'never run npm with sudo' and ranting in dramatic fashion to try and overcome the effect of the printed advice which npm used to output in most failure situations to 'try re-running the command with sudo.' This tended to cause developers new to the ecosystem to re-run the command with sudo and create lots of problems for themselves -- in addition to being an extremely bad security practice. Honestly -- I think npm should be updated to exit without doing anything if it detects its run with root privileges ...

deleted 9y ago

[deleted]

nwhatt 9y ago

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.

dlandis 9y ago

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 9y ago
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.

master-litty 9y ago

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

homulilly 9y ago
I guess they're just refusing to acknowledge that upgrading npm installed the "prerelease" version?
enzanki_ars 9y ago
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.org/post/171169301000/v571 https://web.archive.org/web/20180222201315/http://blog.npmjs...

kuon 9y ago

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 9y ago
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 9y ago
  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.

jehlakj 9y ago

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

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

RX14 9y ago

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#issuecomment-247970222 https://github.com/crystal-lang/crystal/pull/3328#issuecomme....

digi_owl 9y ago

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

jxkcicickgkicu 9y ago

Why would reporter run sudo npm???

45h34jh53k4j 9y ago
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.

coreycoto 9y ago

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.

Sujan 9y ago

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

jt2190 9y ago
http://blog.npmjs.org/post/171169301000/v571 http://blog.npmjs.org/post/171169301000/v571
Nadya 9y ago
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-367726819 https://github.com/npm/npm/issues/19883#issuecomment-3677268...
- Sujan 9y ago
  This is relevant to the information I posted in my comment here how? It is not.

Sujan 9y ago

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.

akras14 9y ago

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

_Chief 9y ago

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.

homulilly 9y ago

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

my_ghola 9y ago
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 9y ago
  yarn use npm registry behind the scene.

InclinedPlane 9y ago

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.

officialchicken 9y ago

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 9y ago
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 9y ago
  How does NPM protect from namesquatting now?
  - teamhappy 9y ago
    http://blog.npmjs.org/post/168978377570/new-package-moniker-rules http://blog.npmjs.org/post/168978377570/new-package-moniker-...
TAForObvReasons 9y ago
The left-pad debacle was a registry issue but the current issue is an npm client issue. In my experience, NPM 5 client versions have been shaky and unreliable, and there are problems with popular ecosystems like react-native [0]. I always roll back to npm 4, even on node 9. [0] https://github.com/facebook/react-native/issues/14209 https://github.com/facebook/react-native/issues/14209

ashtonian 9y ago

https://www.dayssincenpmbroke.com/ https://www.dayssincenpmbroke.com/ accepting PRs: https://github.com/Ashtonian/dayssincenpmbroke.com https://github.com/Ashtonian/dayssincenpmbroke.com

rootlocus 9y ago
Do you really need google analytics for this?
- ashtonian 9y ago
  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 9y ago
    > 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 9y ago
      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.

my_ghola 9y ago

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?

whatever_dude 9y ago

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.

johnvega 9y ago

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.

tuananh 9y ago

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 9y ago
> 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 9y ago
  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.

erulabs 9y ago

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-asynchronous/ https://blog.ometer.com/2011/07/24/callbacks-synchronous-and... 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 9y ago
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.

x2e2l2a 9y ago

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.

atilkan 9y ago

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