This was preventing `node-gyp` from installing the Node header files on
Windows and was the reason that `minimatch` was not being found, as seen
in https://github.com/meteor/meteor/pull/8831.
The `minimatch` module was present, but it was just in `dev_bundle/lib`,
not in `dev_bundle/lib/node_modules/npm/node_modules`.
This expecation may have been expected from older versions of npm but is
no longer the case. This replicates the behavior of the Unix
`generate_dev_bundle.sh` script, which also does not nest `node-gyp`.
/cc @benjamn
Based on this warning:
npm ERR! As of npm@5, the npm cache self-heals from corruption issues and
npm ERR! data extracted from the cache is guaranteed to be valid. If you
npm ERR! want to make sure everything is consistent, use 'npm cache
npm ERR! verify' instead.
npm ERR!
npm ERR! If you're sure you want to delete the entire cache, rerun this
npm ERR! command with --force.
There have been a number of commits in the history for `rimraf` which
indicate others have also been struggling with ENOTEMPTY, specifically
on Windows.
https://github.com/isaacs/rimraf/commits/master
This commit, included in 2.6.1 takes a relatively aggressive approach:
d53235de86
However, due to the way the Windows filesystem is designed, this
approach may be the only way of coping with file-handles which are
cached by the OS and not released immediately upon closing a file
(in other words, at a time that Meteor would think it'd be safe to
remove the file/directory).
Attempts to help with meteor/meteor#8485.
This fixes a bug affecting namespace imports/exports such as
export * from "module"
import * as ns from "module"
where "module" is a CommonJS module that sets module.exports to an
object-like value that is not actually an object, e.g. a function.
The reify commit that fixed this bug includes a test demonstrating an
example of one such library (lodash):
benjamn/reify@b69a600e65
