(Also mark them with "(slow)" to skip them during a normal `npm test`.)
This is mostly the result of a particularly frustrating debugging
session when I couldn't figure out why these tests were timing out
(it turns out, it was because my DNS was broken so `IPTools.lookup` was
timing out). Marking them with "(network)" should make similar
situations less frustrating in the future.
A few uses of `array.sort()` have been left alone:
- sorting in `data/` because they aren't supposed to import anything
- `set-importer` because I still have no clue what that's for and what
dependencies it is/isn't allowed to have
- `sort()` with no arguments used as a lexical sort (at which point
`sortBy` offers no benefits)
All other cases have been replaced with `Utils.sortBy`, which should
be a massive increase in readability.
Sort orders should be much more readable now, without needing to puzzle
through sign issues. The order is always low-to-high, A-to-Z,
true-to-false.
This involves a huge refactor for how battles are constructed, but
it's totally worth it.
Currently, tournaments, challenges, and laddering are unsupported; only
unrated searches work. But it does work, and it's beautiful.
Matchmaking unit tests currently rely on destroying and re-creating a
user causing them to forget about battles they're in, which is not
actually supposed to happen, and breaks #7815.
* Chat monitor: Improve the handling of usernames
This PR ignores word boundaries in evasion regexes when filtering usernames, preventing the use of usernames with evasions of slurs in them.
* properly fix merge conflicts
- Default precision is now 3.
(Instead of "3 months 25 days 17 hours 46 minutes 40 seconds", it'll
say "3 months 25 days 17 hours". You can still set the precision to
`Infinity` if you actually prefer that.)
- Now displays "forever" for Infinity or overflow durations
- No longer skips blank precision levels
(Shows "3 hours 0 minutes 10 seconds" instead of
"3 hours 10 seconds")
It turns out that when I switched us from `assert` to `assert.strict`,
I didn't actually update any existing tests or tell anyone:
0df0d234f2
So apparently everyone else just kept on using `strictEqual`.
This will be a PR and also throw an error if people continue trying to
use it, which should make it much clearer what PS policy is on this.
A lot of the problem may be that TypeScript marks assert.strict.equal
as deprecated when it's not. This was fixed 4 days ago:
https://github.com/DefinitelyTyped/DefinitelyTyped/pull/48452
But this probably hasn't made it to a thing yet. Until then, you'll
have to deal with TS marking your tests as deprecated, but it shouldn't
be too long.
Accidentally using `assert` instead of `assert.strict` should now show
an error. This protects against the probably much worse mistake of
accidentally using `assert.equal` rather than `assert.strict.equal`.
`assert.ok` is also deprecated now.
