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 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
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
This is a change that was necessary on the wip-upgrade-to-node-6 branch,
and it seems better to ship it sooner rather than waiting:
meteor/meteor@d823812e85
The `winston` npm package is not an ECMAScript module, but it does export
a "default" property, and this property was accidentally clobbering the
"default" property of the namespace object, thus interfering with default
import syntax:
import winston from "winston"
Specifically, the `winston` variable would end up referring to
`require("winston").default`, rather than `require("winston")`.
Nothing is lost by fixing this problem, as you can still refer to
`winston.default` if you need to access that property.
Reported by @fermuch here:
https://github.com/meteor/meteor/pull/8327#issuecomment-304721401
Fixed by this commit:
20fdd10d04
