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.
Not having prefer-const on the JS side makes JS -> TS refactors really
unreadable. This commit just auto-fixes it so we're using
`prefer-const` everywhere.
- Centiskorch was misspelled in formats-data, causing a crash in the
egg validator
- A few validation errors were due to Gen 6 not inheriting from Gen 7,
Gen 7 not having a scripts file, and Gen 8 having a gen of 7
- Intimidate (Gen 7) wasn't inheriting from Intimidate (Gen 8), giving
it no name, causing a few validation errors
(Technically not a build error, but I also added Keen Eye to the list
of Intimidate immunities, as reported by SadisticMystic.)
- A lot of tests relied on Teleport always failing; these have been
switched to Gen 7 or swapped Teleport for Celebrate
- Inverse Mod suddenly stopped working; its implementation was a huge
hack and I can't figure out what went wrong, so I've switched it to
using the same system the other mod tests use. It's still a huge
hack, but I don't have the free time to fix it right now.
