Since the -beta152.1 suffix is redundant with the meteor-tool version and
the release version, I'm using just -beta.1 for those versions, but I'm
using -beta152.1 for all other package versions, to avoid overlap with
versions previously published on the release-1.6 branch.
The pull request corresponding to our fork is not going to be merged, so
it's better to use the alternative this.finished API available in newer
versions of the upstream package.
https://github.com/williamkapke/node-eachline/pull/4
The 1.6-beta.7 release had a version conflict because of the webapp@1.3.17
constraint in server-render/package.js. I noticed the problem before
publishing the release, so we will just skip to 1.6-beta.8.
The pull request corresponding to our fork is not going to be merged, so
it's better to use the alternative this.finished API available in newer
versions of the upstream package.
https://github.com/williamkapke/node-eachline/pull/4
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.
