Source is poinitng to internal uber repo about asap HOT 3 CLOSED

Figured it out. TL;DR npm cache clean, rm -rf node_modules, rm npm-shrinkwrap.json if you’ve got one, get a new version of npm, npm install.

If you npm install something, the packages get cached. If you use a proxy for the npm registry, it gets cached with a resolved URL pointing to your mirror.

In the course of their work, an Uber engineer added asap to npm proper to fix a bug. npm/npm#13021

Unfortunately, the copy of asap they committed to npm came from their cache and had been installed via a mirror. This infected package.json was published in npm versions 3.10.0–8.

My theory is that it is only possible way for the infected version of asap to get into your cache if you used npm install npm and got one of those versions. From that time until I published asap 2.0.5, you would receive asap from cache with the mirror resolved, which would not work very well.

That at least limits the scope of the problem and explains why I haven’t heard of this problem before.

In any case, the usual remedies apply. Use npm cache clean, install a recent version of npm, purge the infected version of asap from your project, and remove it from your shrinkwrap. Leave a sacrifice for Zalgo and let me know if you feel better in the morning.

And I probably should let @iarna who appears to be releasing npms these days know this happened.

from asap.

That is decidedly odd. I will look into this. Might be some unwanted cross pollenation via shrinkwrap.

from asap.

I have indeed committed asap with a package.json that was served by an internal registry proxy here: https://github.com/lxe/npm/blob/276a13fc9d099a401ceed9ac4b17bcef3241dae7/node_modules/asap/package.json.

Since it's a bundleDependency, it did not affect npm installations, and the package.json would only be read when one attempts to reinstall the modules. This has since been fixed.

from asap.