Unfortunately, `fs-extra` is still not as perfect at handling various
file system conditions as would be ideal. It seemed sensical to try and
use a library like this however, it turns out that the Meteor suite
of file system functions stands up best on Windows, which is where I
encountered most problems.
For example, `fs-extra` still tries to create symlinks as an unprivileged
user – a forbidden task on Windows unless running as Administrator.
In addition, I ran into a constant stream of other errors: `ENOTEMPTY`,
`EBUSY`, `EEXIST` – all for various reasons.
My current recommendation is that we remove `fs-extra` and replace the
`Builder#complete` `renameDirAlmostAtomically` call (which does not
absolutely _have_ to be done atomically) with a `try`/`catch` which
resorts to a basic copy if `err.code === 'EXDEV'`. All other
functionality stays the same.
This reverts commits:
* d49f3e2704
* 3257bafc84
* 74cb8ebdc2
* 5bbdcc9baa
* 6a0767bbac
* Improve `fs-extra.move` calls for Windows platform.
This is a follow-up to meteor/meteor#8491 which worked properly on Unix
platforms, but failed in a variety of ways on Windows due to its lack
of Fiber-awareness and desire to create symlinks as unprivileged users
(something not always possible on Windows).
The Fiber issue was observed when trying to remove "src" directories
within the `move` function (which tries a variety of OS/OS/arch-specific
techniques to accomplish its goal) after they had been copied to "dest".
On Windows, this resulted in `EDIRNOTEMPTY` errors since Windows appears
to temporarily cache the file-handle or doesn't release the file-handle
until the next tick.
The symlink issue will hopefully improve in an upcoming release of
Windows (Creator Edition) when Microsoft makes it possible to create
symlinks as an unprivileged user, however it will still require enabling
"Developer" mode in Windows settings. This implements the same catch
which was already in place for `fs.rename` on the `fs.move` provided by
`fs-extra`.
Performance gains were the same in tests comparing before and after
these changes.
Relates to:
https://github.com/meteor/meteor/issues/8558#issuecomment-291194385
* A few code-cleanups to my original commit.
This is in an attempt to resolve a situation which could occur when the
extraction of the dev_bundle.tar fails with an EOF error, but the tool
continues as if the file was fine. Ultimately the, error preference
set in the PS1 script is only observed in the case of PowerShell
ErrorLevel and not just an error condition encountered in a command.
We (@abernix and I) have decided to abandon 1.4.3.3 in favor of 1.4.4,
because the changes we wanted to include are slightly more significant
than seems appropriate for a "patch" update.
This change allows the Windows "Generate Dev Bundle" script to
automatically get the versions of major bundled versions from the same
script which the Unix script uses, thus preventing different versions of
Node.js, npm, Mongo, etc. from being built into different versions of
Meteor, such as what happened when I published Meteor 1.4.3.2 and failed
to notice the duplication of variables across different scripts.
This behavior now works in a similar way as the 'BUNDLE_VERSION' variable, which
is retrieved from the global `meteor` script except this change uses the
package versions from the `build-dev-bundle-common.sh` script in the
`scripts` directory.
In a similar fashion as:
* f51c6822ae (Node.js)
* 8ea41588ea (npm)
* 3470516f93 (MongoDB)
I overlooked the multiplicity of these version variables when updating the major package versions during the release of Meteor 1.4.3.2.
While I intend on never making this mistake again, I've also opened meteor/meteor#8505 which consolidates these variables to a single location (in `build-dev-bundle-common.sh`) to hopefully prevent this from happening to anyone else!
The most important change in this version is that the Reify compiler is
now just another Babel plugin, so it's possible for other Babel presets
and plugins to run before it.
Fixes#8399.
Fixes#8422.
Fixes https://github.com/meteor/babel/issues/13.
@abernix Bumping the ecmascript version is apparently necessary if the
babel-compiler package has changed, presumably because ecmascript defines
a compiler plugin that uses babel-compiler. Unless the ecmascript version
has been bumped, babel-compiler changes won't appear to have any effect.
