In the past, we used non-type-aware linting in our pre-push hook, as
well as in `npm test`. This was for performance reasons.
In practice, though, we use an eslint cache, which makes even
type-aware incremental linting instantaneous. My rule is that you
should be able to make a small change and lint in under 10 seconds, and
`npm test` should take under 30 seconds, and linting with no changes
(for the pre-push hook) should be under 2 seconds. This is still true
for type-aware linting, so there's no actual need for fast linting.
We've also switched to using `--max-warnings 0` to convert warnings to
errors. This seems to allow them to use the same cache file.
A big improvement here is that `npm test` should now be enough for
testing. I think everyone ran `npm run full-test` for a while because
`npm test` didn't have type-aware lint errors, but now that it does,
you'll be able to use it again and have your tests run a lot faster.
* Lint arrow-body-style
* Lint prefer-object-spread
Object spread is faster _and_ more readable.
This also fixes a few unnecessary object clones.
* Enable no-parameter-properties
This isn't currently used, but this makes clear that it shouldn't be.
* Refactor more Promises to async/await
* Remove unnecessary code from getDataMoveHTML etc
* Lint prefer-string-starts-ends-with
* Stop using no-undef
According to the typescript-eslint FAQ, this is redundant with
TypeScript, and they're not wrong. This will save us from needing to
specify globals in two different places which will be nice.
This removes Harden from Kakuna and Dragon Rage from Magikarp.
Harden is incompatible with Poison Sting and String Shot, as Kakuna doesn't learn it upon evolving like Metapod.
https://www.smogon.com/forums/threads/random-battles.3526564/post-8577809
Magikarp only gets Dragon Rage via a Japanese event, and since international RBY mechanics are used, it's impossible for this to be used.
As far as I know, these are the only incompatibilities.
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.
