This means node's crypto.randomBytes on the server, and
window.crypto.getRandomValues on the client. If node's crypto.randomBytes throws
an exception, we fall back to crypto.pseudoRandomBytes. If
window.crypto.getRandomValues isn't supported by the browser, we fall back to
the alea generator that we had been using previously.
This package was always included in apps, and even if it was possible to remove,
there wasn't a compelling story about when users would remove and replace
it. Plus, not all backwards-compatibility code could even live in it (eg, field
names of objects), so it was incomplete. It also introduced odd load order
constraints.
Instead, we introduce two conventions for backwards-compatibility code:
- Special comments of the form "// XXX COMPAT WITH 0.6.4"
- When feasible, put backwards-compatibility code in a file called
"deprecated.js" in the relevant package.
This is documented at:
https://github.com/meteor/meteor/wiki/Meteor-Style-Guide#deprecated-code-and-backwards-compatibility
Additionally, removed some symbols that existed for backwards compatibility with
Meteor 0.4.0 (changes made 10 months ago): Meteor.is_client, Meteor.is_server,
and (in a method) this.is_simulation.
For repeatable unit test failures with "random" data it's useful to be
able to create deterministic random number sequences.
Introduce `Random.create(seed...)` which returns a object with the
`Random` API (`id()`, `choice()`, etc.) initialized with the passed
seed(s).
