* 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 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.
* Generally simplifies error handling in browsers
* Makes Jasmine's own integration tests easier to debug
* Stack traces will be provided for more global errors
* ... but less error information will be provided in some browsers if the
error comes from a file:// URL (use `npx serve` or similar instead)
* Jasmine will no longer override existing onerror handlers in browsers
* Setting window.onerror will no longer override Jasmine's global error
handling (use jasmine.spyOnGlobalErrors instead)
It's possible for async code to cause an error when Jasmine
doesn't have any listeners registered internally. This causes
Jasmine to crash (Node) or log to the console (browser)
because of trying to call the nonexistent handler. This change
doesn't fix the overall problem but it does ensure that the
original error is logged rather than Jasmine's internal error.
