This also makes it possible to disable it in places where we were not
checking against the `METEOR_DISABLE_FS_FIBERS` env. variable, like in
`rm_recursive`.
The `rename` is not sufficient on its own since it won't pave the way
for the new directory by ensuring that it's empty first.
`renameDirAlmostAtomically` will do that.
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
Previously, we captured and displayed shorter error messages for the
more complicated and unnecessarily verbose messages which npm produced.
While updating npm to 4.4.4, I observed the changelog for 4.4.0
indicated it would now produce less verbose messages. In searching for
possible Meteor conflicts with this, I discovered that
`installNpmModule` had already regressed on providing pretty messages.
This fixes those messages to be parsed properly and adds tests which
ensure if npm changes again that we can capture them.
Follows-up on: https://github.com/meteor/meteor/pull/8562
* 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.
As of npm 4.4.0 this is necessary as it will now self-check once per day
for updates. Meteor pre-bundles the version of npm though so this
message will be confusing to users of the `meteor` tool.
https://github.com/npm/npm/releases/tag/v4.4.0
* Support Google Sign-In in google-oauth package.
Addresses #8253.
* Use Meteor.startup instead of listening for deviceready event.
* Fix mobile-config.js typo.
* Bump accounts-google and google-oauth package versions.
I'm only bumping the patch versions, even though the recent changes to
these packages may seem significant, for two reasons:
1. Bumping the minor versions would force Meteor 1.4.3 developers to
upgrade to Meteor 1.4.4 if they wanted to use these changes.
2. The accounts-google and google-oauth packages without these changes
will stop working completely in two weeks, which is much worse than the
risks of upgrading.
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.
The `wrapFsFunc` function accepts an array of indexes indicating which
arguments are paths. This is particularly important on Windows, due to
the path-conversation which takes place on those strings.
The docs say:
> Indices of arguments that have paths, these arguments will be
> converted to the correct OS slashes
This follows up on the change made from meteor/meteor#8491 which failed
in our release pipeline when publishing for the Windows architecture
for `1.4.4-rc.3`.
Follow-up to 05be2c784c which added new ES6 syntax, but failed to add `ecmascript`.
* Remove ecmascript Object function shorthand notation.
as the `rate-limit` package doesn't currently use `ecmacsript` and using it for just this one instance of ES6 isn't worth it.
* Remove `ecmascript` from `rate-limit` as it is now unused.
* Bump `rate-limit` version in preparation for publishing.
Fixes#8515
In Unix we support adding `TOOL_NODE_FLAGS` when debugging the Meteor
tool itself, however Windows did not currently support it. This should
add that support. As this is a .bat file, I have every reason to
believe that this syntax should work on older versions of Windows as the
syntax of .bat files hasn't changed much.
Helps with meteor/meteor#8513.
This file leaves a lot to be desired, but strong preference to not
remove existing curly-braces on if-statements.
Also removed trailing whitespaces and slight indentation changes
following the changes in meteor/meteor#8520.
Follow-up to 05be2c784c which added new ES6 syntax, but failed to add `ecmascript`.
* Remove ecmascript Object function shorthand notation.
as the `rate-limit` package doesn't currently use `ecmacsript` and using it for just this one instance of ES6 isn't worth it.
* Remove `ecmascript` from `rate-limit` as it is now unused.
* Bump `rate-limit` version in preparation for publishing.
Fixes#8515
In Unix we support adding `TOOL_NODE_FLAGS` when debugging the Meteor
tool itself, however Windows did not currently support it. This should
add that support. As this is a .bat file, I have every reason to
believe that this syntax should work on older versions of Windows as the
syntax of .bat files hasn't changed much.
Helps with meteor/meteor#8513.
