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.
The server now uses the same approach as the client of treating
cosmetic formes as real formes, as documented in `FORMES.md`.
This eliminates the need for the `.forme` and `.speciesid` properties
of `Pokemon`.
`pokemon.id` has also been removed: useful, since it turns out half
of its uses were bugs that should have used `pokemon.species.id`.
In most other similar systems, like TeamValidator, we use `thing.dex` instead of having it extend `ModdedDex`. Battle has always extended `ModdedDex`, though. This changes Battle to match the others.
This should fix an issue with `Battle.data` not being cached.
This also frees up Battle to extend ObjectReadWriteStream<string> in a future update.
