Do not use NPM 5.7

That's not really the issue, I think. Literally everything you install, however legitimate the source and however well-intentioned the people providing it, is "whatever crap" for the purposes of this exercise. What happened here could also have happened using just about anything else you installed on a typical Linux system today, whether from an official distro package repository, or some other source of packaged files, or side-loaded with one of those horrendous "Sure, I'll download your arbitrary script from the Internet and pipe it through sh as root to install your software without even checking it, as you recommend on your web site" things.

There is no reason that our systems should trust arbitrary installation scripts to do arbitrary things, whether they're running as root or not, but especially if they are. I'm stunned at the opposition I'm seeing from so many people on HN to the idea of making a system more secure, even while we're discussing a demonstrated, system-destroying bug in widely used software that was apparently unintentionally rolled out through at least one official channel when it wasn't ready.

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

    if dir !exists:
      mkdir && chown
    else:
      if dir has correct ownership:
        traverse
      else:
        // our code chowns correctly on create
        // so user must have done something
        // independently; better NOT mess with it
        throw "helpful descriptive message"

mkdirp creates OR traverses recursively based on whether each directory already exists or not. This is why correctMkdirp() is an insane idea: the "correct"-ing chown step should never be internal to mkdirp because it should never occur on traversal (i.e. when a pre-existing directory is encountered).

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

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