* 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.
While I'm fairly sure that `0.` bullet points were always changed to correctly-ordered lists in the past on GitHub, however this no longer seems to be the case now and the first bullet-pointed number actually matters (the subsequent points do not and can be zeroes)
* Switch from mailcomposer 0.1.15 -> 4.0.1 (latest, still MIT license).
* Switch from simplesmtp (which only supports mailcomposer 0.1)
to smtp-connection (which supports any mail composer).
* Use smtp-connection@2 (instead of latest) which shares
nodemailer-shared codebase with mailcomposer 4.0.1.
* Add test for long header lines (the original bug being fixed here)
* Add extra test for HTML + text messages
* Document some extra options arguments supported by new mailcomposer
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 gives us all the benefits of @sethmurphy18's great work without the
additional performance hit of using Babili for everything.
With this commit:
% meteor create min-test
% cd min-test
% time meteor build ../min-build
meteor build ../min-build 39.26s user 5.49s system 112% cpu 39.647 total
Without this commit:
meteor build ../min-build 59.28s user 5.23s system 107% cpu 1:00.08 total
Keep in mind this is the best-case scenario for Babili (a very small app).
Larger apps take much longer for Babili to minify.
cc @abernix @glasser @sethmurphy18
Add boolean option 'ambiguousErrorMessages' to Accounts config that sends ambiguous error messages to the client in order to mitigate user enumeration. User enumeration still possible via inference upon registration failure, but at least we’re not being as explicit about the failures.
