* 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
This isn't comprehensive but it should be broad enough to ensure that most
people who would be affected by blocking monkey patching see a warning.
Covers the jasmine namespace as well as classes that are monkey patched by
zone.js.
Replacing globals (describe/it/etc) doesn't trigger a warning because they
belong to the user and are expected to be replaced.
Pretty printing is occasionally useful outside of the places where a
configured pretty printer is injected (matchers and asymmetric equality
testers). Users sometimes use the private basicPrettyPrinter for that.
jasmine.pp is part of the public interface and uses the current runable's
custom object formatters.
New asymmetric equality tester that accepts a variable number of arguments, and will pass if all of them evaluate as being equal to the input value.
Includes unit tests
This reverts commit 6da88ec19eea2780c030dc95fcc55d059fed69e5.
Removing existing handlers turns out to be load-bearing for Jasmine's
parallel mode. ParallelWorker (in the jasmine package) installs a pair
of handlers before booting core so that it can catch late async errors
that happen after one spec file has finished executing and before the
next starts. If those aren't uninstalled, errors that get routed through
jasmine-core's normal error handling mechanism will also be reported
via ParallelWorker's handlers. It might be possible for ParallelWorker
to uninstall and install its handlers at the right time, but it's
likely that there would be gaps in between when core uninstalls its
handlers and when ParallelWorker installs. And in any case, the
old behavior of GlobalErrors was a perfect match for what ParallelWorker
needs, so let's keep it.
