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.
This will enable us to update the less npm package in future versions of
Meteor without worrying about minor version constraints imposed by the
Meteor release.
These changes create a new copy of the static-html and
caching-html-compiler packages in core, as well as a new package
called html-scanner, to house the html-scanner.js functionality
from the templating-tools package. With these changes in place,
we're able to remove all Blaze dependencies from static-html,
which benefits React based Meteor apps.
We don't need the extra `CompileError` class, and using it
was throwing off `caching-html-compiler` error handling.
Errors with messages and line numbers weren't being
interpreted / formatted properly.
