This should have been done when PR #10299 was first merged. Thankfully,
@macrozone discovered the problem while diagnosing issue #10530.
Should fix#10530.
* Update cordova-plugin-meteor-webapp to version 1.7.0.
Fixes#10516.
* Bump meteor-tool and webapp to a temporary 1.8.1-issue-10516.0 version.
I attempted to publish webapp@1.7.4-rc.0 with @rj-david's changes from
https://github.com/meteor/cordova-plugin-meteor-webapp/pull/78 to verify
that they fix#10516, but prerelease versions like 1.7.4-rc.0 are not
compatible with non-prerelease core package constraints like ~1.7.3 (which
desugars to >=1.7.3 <1.8.0), as explained by this comment in the semver
source code: 5fb517b290/semver.js (L1246-L1250)
While this behavior was somewhat surprising to me, I haven't come up with
a way to fix it without accidentally allowing any prerelease version of
core Meteor packages to be installed in applications using an official
(non-prerelease) version of Meteor.
Instead, we can just cut a temporary prerelease version of Meteor itself.
If that fixes the problem, then we can publish webapp@1.7.4 safely,
without actually publishing a Meteor 1.8.1.1 release just for this.
* Update webapp to version 1.7.4 (without -issue-10516.0 suffix).
Now that we've moved into the release candidate phase, there will be no
more new features added to Meteor 1.8.1, and all remaining effort will be
focused on fixing bugs.
Please test the release candidate if you have time, by running the
following command in any application directory:
meteor update --release 1.8.1-rc.0
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.
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.
