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.
While these updates were technically available to Meteor 1.8.0.1 apps, the
Meteor release version did not enforce the updates, and the old versions
were still included in the Meteor 1.8.0.1 dev bundle. In other words,
Meteor 1.8.0.2 is the release where these updates were fully enforced.
New Meteor apps have the following meteor.testModule in their package.json
files by default
"meteor": {
"testModule": "tests/main.js"
}
When meteor.testModule is defined, it determines the test entry point when
running the `meteor test` command, ignoring legacy file naming conventions
like *.tests.js or *.app-tests.js.
The package-source.js code changed by this commit was incorrect because it
ignored those specially-named test files even when running tests, which
was a problem if the meteor.testModule tried to import them explicitly,
because they would not be properly compiled.
If you're using meteor.testModule, the distinction between `meteor test`
and `meteor test --full-app` matters a bit less, since the test entry
point will be the same for both modes, though you can still check
Meteor.isTest and Meteor.isAppTest at runtime to control test behavior.
New Meteor apps have the following meteor.testModule in their package.json
files by default
"meteor": {
"testModule": "tests/main.js"
}
When meteor.testModule is defined, it determines the test entry point when
running the `meteor test` command, ignoring legacy file naming conventions
like *.tests.js or *.app-tests.js.
The package-source.js code changed by this commit was incorrect because it
ignored those specially-named test files even when running tests, which
was a problem if the meteor.testModule tried to import them explicitly,
because they would not be properly compiled.
If you're using meteor.testModule, the distinction between `meteor test`
and `meteor test --full-app` matters a bit less, since the test entry
point will be the same for both modes, though you can still check
Meteor.isTest and Meteor.isAppTest at runtime to control test behavior.
