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.
Safari 15:
* Lacks structuredClone, which is starting to become useful
* Has stack trace quirks that are not well understood, not properly handled
by Jasmine, and can cause problems in Jasmine's own tests
* Is not widely used
* Does not run on any OS that still receives security updates
This isn't officially compatible with the oldest version of Node that
Jasmine supports, but it works. If it stops working, we can always disable
linting in CI builds on older Node versions.
temp has seen some recent maintainer activity but there haven't been
any commits since 2021 and PRs have gone un-addressed for years. It's
one of the dev dependencies that depends on very old versions of rimraf.
These are similar to `expect` and `expectAsync` except that they throw
exceptions rather than recording matcher failures as spec/suite failures.
They're intended to support using Jasmine matchers in testing-library's
`waitFor`, and also provide a way to integration-test custom matchers.
These funtions are not equivalent to `expect` and `expectAsync` and should
not be used in situations where you want a matcher failure to reliably fail
the spec. Whether that happens depends on the structure of the surrounding
code. In general, you should only use `throwUnless` when you expect
something (which could be your own code or library code like `waitFor`) to
catch the resulting exception.
Fixes#2003.
Fixes#1980.
Not updating Prettier because newer versions impose significant formatting
changes. In particular, 2.0 changes every function definition from
`function() {` to `function () {` with no way to opt out. I'm not willing
to accept that kind of churn just becuse the Prettier devs changed their
mind about what color the bikeshed should be.
We'll most likely stay on Prettier 1.17 for as long as it remains viable,
then either switch to an autoformatter that offers stability or just
remove it.
