Removing garbage directories asynchronously in
Example stack trace:
This would have been a nice optimization if it had worked, but (in addition to leaving garbage directories lying around sometimes if the process was killed), it appears to have some unintended consequences for meteorNpm.rebuildIfNonPortable and related functions, since the garbage directories are easily confused for npm package directories. Example stack trace: Error: ENOENT: no such file or directory, open '/home/travis/build/meteor/galaxy-server/node_modules/heapdump-garbage-1c2jqib/package.json' at Error (native) => awaited here: at Promise.await (/home/travis/.meteor/packages/less/.22.214.171.124fh5c1++os+web.browser+web.cordova/plugin.compileLessBatch.os/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:39:12) at copyFileHelper (/tools/fs/files.js:633:6) at Object.files.cp_r (/tools/fs/files.js:532:7) at /tools/isobuild/meteor-npm.js:393:11 at Array.forEach (native) at copyNpmPackageWithSymlinkedNodeModules (/tools/isobuild/meteor-npm.js:386:29) at /tools/isobuild/meteor-npm.js:325:5 at Array.forEach (native) at Object.rebuildIfNonPortable (/tools/isobuild/meteor-npm.js:315:17) at NodeModulesDirectory.rebuildIfNonPortable (/tools/isobuild/bundler.js:273:22) at /tools/isobuild/compiler.js:650:13
Also bumping the ecmascript version because it registers a compiler plugin that uses babel-compiler. Fixes #8572, albeit somewhat hackily.
@laosb We haven't forgot about it.
Meteor 126.96.36.199 is still the "recommended" release at the moment and we are working to officially recommend 188.8.131.52 as soon as possible, but we're not quite there yet. Of course, anyone is free to help test it right now though, and we'd appreciate the extra feedback!: