These browsers have bugs that occasionally cause typed array comparisons
to pass when they should fail, or vice versa:
* for...in loops sometimes omit keys, such that two typed arrays with
different lengths appear to have the same set of keys.
* Typed arrays sometimes have mulitple undefined keys (which is to say that
the key itself is undefined). Two typed arrays with identical length and
contents can compare unequal because of the spurious undefined keys.)
Those problems could be avoided by comparing keys 0...length-1 rather than
the actual set of exposed keys, but that would be a pretty nasty breaking
change for anyone whose code tacks extra properties onto typed arrays. So
far these bugs haven't been seen in anything newer than FF 128. Since the
affected browsers are all past end of life, the most sensible thing is to
just stop testing against them.
The old style of merging all of a function's variable declarations into
a single statement made some sense back in the days of var, but there's
no reason to keep doing it now that we use const and let.
* Assert that the right inner stack traces are in the right places
* Drop the integration tests. All of the AggregateError-specific code
is in ExceptionFormatter, so the integration tests just duplicate
existing integration tests and the ExceptionFormatter specs.
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
Injected DOM wrappers were a nice idea in theory but everyone just passes
wrappers around document.createElement/document.createTextNode. That
includes HtmlReporter's unit tests and karma-jasmine-html-reporter, the
only known 5.x-compatible library that constructs an HtmlReporter.
