* Top level private APIs (e.g. jasmine.private.whatever) are no longer
exposed
* jasmineRequire is no longer exposed
* core is self-booting
* Globals are automatically created in browsers. (They can subsequently
be removed by user code if desired.)
* Globals are *not* automatically created in Node. An installGlobals
function is exported instead. The jasmine package calls installGlobals
unless configured not to do so.
* In Node, the same instance is returned each time jasmine-core is
imported. A reset function is exported. It effectively resets all state
by discarding the env and creating a new one. This allows mulitple
sequential runs within the same process to be independent of each
other, but does not allow multiple concurrent runs. (That probably never
worked anyway.)
Fixes#2094
Previously, a custom matcher library that wanted to remain compatible with
Jasmine <= 3.5.x could not know whether or not Jasmine expected it to pass
custom equality testers to MatchersUtil#contains. Passing them would produce
a deprecation warning in newer versions and not passing them would break
compatibility with older versions. Now we use matcher factory arity to
determine whether to pass custom equality testers to the factory, which
allows libraries to do something like this:
function matcherFactory(util) {
const customEqualityTesters = arguments[1];
// customEqualityTesters will be undefined in newer versions of Jasmine
// and defined in older versions that expect it to be passed back to
// MatchersUtil#equals.
}
This will allow us to add support for custom object formatters, which
will be a per-runable resource like custom matchers, by injecting them
into the pretty-printer.
