We've seen some recent intermittent test failures because previous
CallbackLogger results were accidentally carried over when there should be
no results. This change allows running a callback function after resetting
logger._log.length to 0, to ensure the callback adds nothing to the log.
Self-tests that are marked as "slow" are not run automatically for pull
requests, but they should be run before a release.
It was a mistake to publish the first Meteor 1.6.1 release candidate
without running these "slow" tests, as the cordova-builds test would have
caught the problem reported by @macrozone in #9521.
I've decided to remove the "slow" marker from this test, since it's
important for checking Cordova sanity, and clearly could fail.
In order to install Gradle, which is required for Cordova tests to run
in the Meteor self-test suite, this image slightly builds upon the
CircleCI image we'd been using previously.
This is potentially a big change, though it should (with any luck) make
tests faster, and allow us to better test Cordova functionality (at least
as far as Android is concerned). For example, if this works, we won't have
to mark the "cordova builds with server options" self-test "slow" again,
which would (re)disable it during Circle CI test runs.
cc @abernix @hwillson
* Change error suppressing property in livedata_connection.js
Fixes#6912
Switched the property from `expected` to `_expectedByTest`
* Update History.md and bump package patch versions
PR #9343 changed the return type of Boilerplate#toHTML from String to
Stream, which is likely to break existing code that expects a string.
In order to make the change in return type more obvious, I have renamed
the method to toHTMLStream, and I have attempted to update all call sites
appropriately. However, because this change comes in the release candidate
phase of Meteor 1.6.1 testing, it seemed important to preserve the
string-returning behavior of toHTML, with a deprecation notice.
Unless third-party code is using the Boilerplate class directly, I don't
think the toHTML method will ever be called, and we can remove it in
Meteor 1.6.2.
Thanks to @macrozone for tracking this problem down.
Fixes#9521.
These changes are needed to get the plugin meteor-coverage working. IstanbulJS (shipped with meteor-coverage), can only generate the coverage-report for the code loaded after it's initialization. This is why the code, the plugin meteor-coverage contains, must be executed before the code is loaded, which should be tracked in the code-coverage. A suitable check I found was when a debugger isn't used, which makes it impossible to use code-coverage and the debugger at the same time. It's the only feasible condition I could come up with.
The package meteor-coverage also registers a hook of IstanbulJS which overwrites `vm.runInThisContext()` in order to start the coverage. As of now, IstanbulJS does not support overwriting `vm.Script.runInThisContext()`.
https://github.com/meteor/meteor/pull/9274#issuecomment-355241004
The `Error in connection establishment: net::ERR_CONNECTION_REFUSED`
message will still repeat every few seconds, but devtools should coalesce
it into a single line with an incrementing counter, as before.
This is a back-port of a similar change on the web.browser.legacy branch:
b8601d3ce7
To save size in modern browsers, JavaScript bundles built for the
web.browser architecture no longer statically include the SockJS library.
That's safe as long as native WebSockets actually work, but what if
there's a problem with the network that necessitates falling back to
long-polling or some other SockJS strategy?
In those cases, we can load SockJS using a dynamic import(), which is a
little slower than including it in the bundle, but that's OK because the
module will be permanently cached in IndexedDB in production, and falling
back to SockJS should be rare in modern browsers anyway.
Note that this trick would not be possible if the implementation of
dynamic import() still required a socket connection! (#9384)
Client side `Accounts.onLogin` callbacks are triggered after a
successful login, but they're also triggered after a successful
DDP reconnect (if already logged in). As discussed in #5127,
some people think this is the correct behaviour, while others
feel that `onLogin` callbacks should really only fire after a
user has actually logged in (e.g. after using something like
`Meteor.loginWithPassword`). Since people are split on the
proper approach here, an alternative solution would be to
provide client side `Accounts.onLogin` callbacks with a way
to tell if they're being called after a login or after a
reconnect, then let them decide what to do.
Server side `Accounts.onLogin` callbacks receive an object that
contains various login details. One of those items is a login
`type`, that can hold values like `password`, `resume`, etc.
When a user completes a true password based login, the returned
login `type` is `password`. When the user is already logged in
but undergoes a DDP disconnect + reconnect, the returned login
`type` is `resume`. This means server side `Accounts.onLogin`
callbacks have a way to tell which type of login is happening,
allowing them to respond accordingly.
This PR adjusts client side `Accounts.onLogin` callbacks such
that they also receive a single login details object, that
contains login type information. Unlike the server side login
details object, the client side login details object only
contains the login type (to help reduce network transfer
overhead, make sure we're not exposing server details on the
client we shouldn't be, etc.).
This approach should give developers a better way to respond to
different client side login types, and act accordingly.
Fixes#5127.
All external service `accounts-*` packages (`accounts-facebook`,
`accounts-github`, etc.) are currently using ES2015 syntax, but
do not explicitly declare a dependency on the `ecmascript`
package. This means the ES2015 syntax being used is not
transpiled by Meteor, and can lead to issues like #9506.
Since `accounts-base` and `accounts-password` both already
have `ecmascript` as a dependency, this PR adds an `ecmascript`
dependency to all external service `accounts-*` packages.
Fixes#9506.
This commit updates the `meteor create --full` app skeleton to use `meteortesting:mocha`
(and npm based `chai`), instead of the deprecated `practicalmeteor:mocha` package.
