This minimizes side effects of import/require across the codebase,
and lets the caller be responsible of initializing child processeses,
as well as other async logic, such as restoring saved battles.
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.
* Prevent guessing words with incorrect already revealed indexes
* Clarify hint length and use consts
* Escape HTML on words
* lint
* Hangman: Better testing for invalid guesses
* Hangman: Escape HTML characters
Co-authored-by: Leonard Craft III <leonardcraft64@gmail.com>
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
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.
I couldn't completely remove the global room in one commit, but this
solves basically every problem with it by making it no longer a `Room`.
In particular, this means:
- It's no longer of type `Room`
- It's no longer in the `Rooms.rooms` table
- Its class name is now `GlobalRoomState` rather than `GlobalRoom`
- It no longer tracks its own user list (online user count is now
provided by `Users.onlineCount`)
- It's no longer a socket channel (there's new syntax for "send this
message to every user")
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.
