* 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.
Previously, while the `useragent` package was able to parse the User-Agent
for so-called "Headless Chrome" and generate a family of "HeadlessChrome",
it was unable to parse out the individual portions of the version number
(e.g. major, minor, patch).
For example, the following User-Agent (herein referred to as `userAgentAbove`):
```
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/69.0.3497.100 Safari/537.36
```
Previously resulted in:
```
> require('useragent').lookup(userAgentAbove);
{
family: 'HeadlessChrome',
major: '0',
minor: '0',
patch: '0',
/* ... */
}
```
With the newer version of `useragent`, these are now properly extracted and
set which will enable Meteor to treat Headless Chrome the same as Chrome in
a follow-up commit. Now:
```
> require('useragent').lookup(userAgentAbove);
{
family: 'HeadlessChrome',
major: '69',
minor: '0',
patch: '3497'
/* ... */
}
```
When generating boilerplate, meteor runtime config includes additional
options based on the arch.
However, these additional options were not present when generating
the response to `/meteor_runtime_config.js`, which is used when
inline scripts are disabled.
This change fixes Meteor.isModern in those circumstances.
