1a036553 in 1.4.4.2 expanded on the HTTP error checking added by 30aec9f in
1.4.2. Neither of these changes were aware that discoverGalaxy invokes
httpHelpers.request with json:true, resulting in a `body` that is a parsed JSON
object rather than a string or Buffer. Before 1.4.4.2, this had no consequences
because body.length is undefined and `undefined < 90` is false, but the change
to Buffer.byteLength actually made the condition true.
It's safe to not check length in the JSON case because a truncated JSON object
is not legal JSON (unless the truncation just drops trailing whitespace, in
white case that's OK).
I check for both string and Buffer because some calls to this function pass in
an encoding option. Buffer.byteLength works with both types.
This method appears to be causing large spikes in memory consumption on
Circle CI during the `meteor --get-ready` preparation step, which often
leads to the test process being killed.
Also added a call in IsopackCache#_loadLocalPackage for good measure.
We're now calling requestGarbageCollection pretty frequently when
we run Node with --expose-gc, but that currently only happens during
Circle CI tests, so I don't think we need to implement the improvements
suggested in tools/utils/gc.js, yet.
Previously: 35f488e140, f6df21ff1e
To deal with individual flaky tests, we often just re-run the entire test
suite, which feels like an enormous waste of shared computing resources.
This change automatically re-runs individual failed tests as many as two
more times, and considers the test successful if any of those attempts
succeeds.
cc @abernix @hwillson et al.
* Implement CORDOVA_COMPATIBILITY_VERSION_EXCLUDE and CORDOVA_COMPATIBILITY_VERSION_IOS/ANDROID
CORDOVA_COMPATIBILITY_VERSION_IOS or CORDOVA_COMPATIBILITY_VERSION_ANDROID allows to override compatibility version for a specified platform.
CORDOVA_COMPATIBILITY_VERSION_EXCLUDE provides a way of excluding a certain plugin from compatibility version calculation. You can pass several plugin names with ';'. For example: `CORDOVA_COMPATIBILITY_VERSION_EXCLUDE='cordova-plugin-crosswalk-webview;cordova-plugin-device'`
* Changes after review
The comma in question: a trailing comma a rest-parameter, within a
function argument's parameter de-structuring:
function a({
a = false,
...b,
}) {
// ...
}
Espree, the parser used by `jsdoc` (used in Meteor docs) previously
allowed this with `experimentalObjectRestSpread` enabled but now throws
an error with the addition of 652990a7bf.
It might have been argued at one point that the trailing-comma could
allow for the easy, future addition of another parameter, ala:
function a({
a = false,
...b,
c = true,
}) {
// ...
}
Having the rest-parameter in the last position is certainly more clear
(it is the "rest", after-all, and there can be only one) but I'm not
going to have that discussion at the cost of docs not deploying!
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/.2.7.9.9fh5c1++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
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.
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`.
Presently, the renaming of directories that are in-use will fail on
Windows. This is already compensated for when `process.platform` is
set to `win32`. However, within BashOnWindows/WSL (Windows Subsystem
for Linux), `process.platform` is equal to `linux`, though the
underlying filesystem is still the same.
Microsoft has stated that it is unlikely that they will remove
`Microsoft` from the `os.release()` value so we check for that.
This simple fix prevents the disappointment of trying to deploy your app
but failing because there's a space on the end of the `DEPLOY_HOSTNAME`
environment variable.
`process.env` always contains string values and assigning a property on
`process.env` implicitly converts the value to a string so it should not
be necessary to check if `typeof` is a `string`.
Fixes Dev Experience.
Windows has no concept of the executable bit so it is not applied by the
`fstream` `Reader` when building the tarball which is used in both
`meteor build` and `meteor deploy`. For Windows users, this causes
important scripts (such as `node-pre-gyp`) to not be executable when
the bundles are deployed to Unix platforms (such as Galaxy).
To avoid giving every file executable bits, this applies an executable
bit to the file only if it has read permission (something Windows _is_
aware of) and if it is in a location that Node bin links are typically
placed, the `/node_modules/.bin/` directories.
We now check `package.json` in order to help make an educated decision
as to whether or not a package has binary dependencies which need to be
rebuilt. In some cases, such as the `npmconf` npm which is included
as a dependency of `flow-router, the `package.json` is invalid (i.e.
empty), and we should silently permit this.
Fixesmeteor/meteor#8427
This is a developer experience (DX) change.
In production, the `METEOR_SETTINGS` environment variable is used to
pass parameters which will be available in the `Meteor.settings` within
the app. However, `METEOR_SETTINGS` is ignored when using the
`meteor-tool` itself as in development, environment variables are
often less desirable. Additionally, there would be no reactivity when
changing settings was necessary, instead requiring that the `meteor`
tool be restarted entirely.
On more than one occasion, developers have been confused as to why the
`METEOR_SETTINGS` are not respected in development. To make it more
clear when this is attempted (and clarify that they will _not_ be used),
provide the a clear warning before ignoring the `METEOR_SETTINGS`
variable.
Aims to avoid meteor/meteor#8455.
