When we run 'meteor test-packages' as part of our Circle CI test rotation,
we happen to be testing the Meteor `jquery` package along with all of our
other packages, so it has a chance to define `window.jQuery` globally, so
everything seems to work.
However, if you run `test-packages` with a subset of packages that does
not include or depend on `jquery`, there will be errors in the browser
console about `jQuery` not being defined, because the `test-in-browser`
package depends on `blaze`, which implicitly depends on `jquery`.
* remove jquery and deprecated bootstrap dependency in test-in-browser
Another step towards https://github.com/meteor/meteor/pull/10498
The direct jquery dependency was not necessary as far as I can tell. There was a second indirect dependency through the deprecated bootstrap package from which we only need the css.
So I replaced that one with bootstrap 4 css from npm
* Improve styling for test-in-browser
This hack dates all the way back to 2013: a2c4a78743
Though it is convenient to reload the browser when server files change
while running test-packages, that's not the behavior of most Meteor apps
that use the autoupdate package, and this hack introduced a signficant
difference in behavior between the test-in-browser and test-in-console
driver packages, which finally surfaced due to the interaction between
@toinevk's headless testing PR #9814 and my refactoring of the autoupdate
package (fe9e4035f9). Tests should behave
the same regardless of which driver package is used.
It turns out there's a better way to make the browser reload each time the
server restarts: simply modify Meteor.settings.public, since that object
is included in the client hashes computed by the webapp package.
Since jquery used to be a core package, and the most recent Meteor release
(1.6.1.1) imposed the ~1.11.11 constraint (note the ~), jquery@1.12.1
won't be usable with Meteor 1.6.x until it is republished after the next
Meteor release, which will no longer constrain the jquery version, because
jquery is no longer a core package (#9607).
In order to publish these two packages sooner rather than later, we need
to relax their jquery version constraints, because we don't want to
publish jquery@1.12.1 yet. The relaxed @1.11.11 constraints in these
package.js files will remain compatible with jquery@1.12.1, so this change
should be safe for the forseeable future.
