ESLint has a whole new config format, so I figure it's a good time to
make the config system saner.
- First, we no longer have separate eslint-no-types configs. Lint
performance shouldn't be enough of a problem to justify the
relevant maintenance complexity.
- Second, our base config should work out-of-the-box now. `npx eslint`
will work as expected, without any CLI flags. You should still use
`npm run lint` which adds the `--cached` flag for performance.
- Third, whatever updates I did fixed style linting, which apparently
has been bugged for quite some time, considering all the obvious
mixed-tabs-and-spaces issues I found in the upgrade.
Also here are some changes to our style rules. In particular:
- Curly brackets (for objects etc) now have spaces inside them. Sorry
for the huge change. ESLint doesn't support our old style, and most
projects use Prettier style, so we might as well match them in this way.
See https://github.com/eslint-stylistic/eslint-stylistic/issues/415
- String + number concatenation is no longer allowed. We now
consistently use template strings for this.
`maxTeamSize` is a bad variable name (not that `teamLength.battle` is
any better, but that'll get fixed in a future refactor).
- Rename `maxTeamSize` to `chosenTeamSize`, to better indicate that
this is the size after Team Preview, and that it is also the minimum
size after Team Preview.
- Don't limit team sizes to 6 if `teamLength.battle` isn't specified.
This removes an unnecessary `teamLength.battle` requirement in all
Custom Game formats.
- Stop requiring `maxTeamSize` as a parameter for `battle.getRequests`.
It's not even used except as a hint to the Preact client, and was
never state in the first place.
- Stop supporting partial `side.chooseTeam`. This is an unused feature
and removing it massively simplifies the code and fixes a bug in
`cupLevelLimit` which definitely was not written with the
understanding that `chooseTeam` could be partial.
- Fix a bug in #7929 which seemed to misunderstand what `teamsize` was
for.
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.
It turns out not creating a format on-the-fly breaks deserialization.
We now just use the same custom-rule system that tournaments use.
Some hacks are currently necessary (many tests assume that we're
playing in Anything Goes rather than Custom Game) but we'll work them
out in time.
