Tests have started failing for reasons that may be related to puppeteer's
Meteor process management: https://circleci.com/gh/meteor/meteor/31035
Since I can't identify any other possible causes, using the same version
of puppeteer that other tests use (e.g. modules, dynamic-import) seems
like a reasonable first step.
Also updated puppeteer in tests/apps/app-config/package-lock.json to
version 1.6.2 (was 1.3.0), in an attempt to fix some unhandled promise
rejection warnings: https://circleci.com/gh/meteor/meteor/31063
This information is useful when you need a unique identifier for the
current version of the application (and you're using Git).
If the current Git HEAD revision can't be found for any reason, the
gitRevision property simply will not appear in star.json or
__meteor_runtime_config__.
This partially reverts commit 99b79dc00f,
which was added as part of PR #10055 in an effort to trigger hot reloads
on the client when/if the definition of a "modern" browser happened to
change, due to server code calling setMinimumBrowserVersions. Although
changes in the minimum modern browser versions are pretty rare, it seemed
important to incorporate this information into the client hash, because
code sent to the client tends to be dramatically different depending on
whether the client is considered modern.
However, this change was made without updating the corresponding version
calculations in CordovaBuilder#appendVersion in tools/cordova/builder.js,
so the versions in program.json for Cordova apps disagreed with the
versions served in manifest.json by the web server, leading to the
problems described by @lorensr in this cordova-plugin-meteor-webapp issue:
https://github.com/meteor/cordova-plugin-meteor-webapp/issues/69
It would be nice to include the minimum versions hash in program.json for
Cordova builds, but unfortunately these versions are not known at build
time, because they are determined by calls to setMinimumBrowserVersions
during server startup. In other words, if we wanted to access that
information during Cordova builds, we would have to start the web server
and run all server-side application initialization code just to find out
if setMinimumBrowserVersions was called anywhere.
In the future, we could consider including the minimum versions hash in
manifest.json, so cordova-plugin-meteor-webapp could compare the current
version to the new version whenever it fetches manifest.json. However, I
think simply removing the minimum versions hash from the client version
calculation is a fine solution in the meantime. If a developer needs to
trigger a hot reload because they changed their minimum modern versions,
they should just be sure to change their client code at the same time.
Any change that would normally trigger a client reload will work.
This version of cordova-android includes the PR that previously required
us to fork the package: https://github.com/apache/cordova-android/pull/417
The cordova-ios update is just 4.5.4 => 4.5.5, so hopefully entirely
backwards compatible. :crossed-fingers:
Fixes#10393.
Bumping compiler.BUILT_BY and LINKER_CACHE_SALT because
PR #10414 changes the behavior of the build system in a subtle way that
does not automatically trigger recompilation.
Besides helping with readability, this refactor fixes a number of bugs,
most notably the assumption that options.passwordSignupFields is an array,
though previously this package accepted a string; and the accidental use
of options.forceApprovalPrompt in code blocks that were supposed to be
handling the other options.
As a side note, I have yet to see a use of Array.prototype.reduce that
actually improved readability or performance, relative to any simpler
alternatives. Don't drink the functional programming kool-aid, y'all.
