No refactors here, either, just some basic changes.
A bug with `ladderget` was fixed, and `errorip` is now only used in
situations where it'd be recognized.
The PHP ladder implementation has been full of tech debt for a while.
Fortunately, TypeScript makes it _much_ easier to refactor this sort of
thing. This is the sort of refactor I never would have bothered
attempting in PHP, but TS makes it really easy to clear all the tech
debt.
The idea of caching a ladder entry in a user object may be useful
in the sim server, but it was really dumb here.
This commit adds a new SQL tagged template string syntax way more
powerful than the old one.
After discussion on Discord, I realized that requiring tagged template
strings and completely disallowing raw strings as SQL would make the
code a lot safer, but tagged template strings just needed a bit more
work to make them bearable for this purpose. I've now implemented said
tagged template strings.
Documentation in the jsdoc above the SQL tag function.
database.ts is much cleaner as a generic database library that can be
used anywhere.
I'm also taking back the `@author` line - this file is based on a
database library I wrote for a different project:
2c55b7b09d/server/db.ts
The file will be mostly mine by the time I'm done with it.
The new names should be clearer. I wanted to do this as part of a
refactor, but doing the rename separately should make the refactor
diff more readable.
Frivolous dependencies are bad for perf and bad for security.
The usual justification for frivolous dependencies is something like
"a community-maintained package is more likely to be bug-free and
maintained than something you wrote yourself", but:
1. frivolous dependencies are usually maintained by Just Some Random
Guy, not by some community
2. you are probably more likely to introduce a bug using some guy's API
incorrectly, than by writing a few lines of raw JavaScript that you
understand inside and out
3. if that guy deprecates his package, or decides to ragequit, or
whatever, you do not want to be depending on it
4. debugging becomes a lot more annoying
5. the dependency is full of unnecessary complexity to support use
cases we're not even using
Anyway, yeah, there's no need for this dependency.
