Necessary for consumers of the DatabaseTable API wishing to use the delete etc functions. And this solution is much nicer than `tableinstance.SQL\`\``.
`./build decl` now builds TS declarations for everything exported by
`sim/`. Unfortunately, the built TS declarations still refer to global
types, so some things still have `any` type, but it's much better than
nothing.
A few uses of `array.sort()` have been left alone:
- sorting in `data/` because they aren't supposed to import anything
- `set-importer` because I still have no clue what that's for and what
dependencies it is/isn't allowed to have
- `sort()` with no arguments used as a lexical sort (at which point
`sortBy` offers no benefits)
All other cases have been replaced with `Utils.sortBy`, which should
be a massive increase in readability.
Sort orders should be much more readable now, without needing to puzzle
through sign issues. The order is always low-to-high, A-to-Z,
true-to-false.
This is the change that renames:
- `Dex.getMove` -> `Dex.moves.get`
- `Dex.getAbility` -> `Dex.abilities.get`
- `Dex.getItem` -> `Dex.items.get`
- `Dex.getSpecies` -> `Dex.species.get`
- `Dex.getEffect` -> `Dex.conditions.get`
- `Dex.getNature` -> `Dex.natures.get`
- `Dex.getType` -> `Dex.types.get`
- `Dex.getFormat` -> `Dex.formats.get`
In addition, some other APIs have been updated:
- `getByID` methods have also been added to every other table.
- `Dex.moves.all()` now gets an array of all moves
- Plus equivalent methods for `abilities`, `items`, `species`, `formats`, `natures`, `types`
- Note: there's no `Dex.conditions.all()`
- new API: `Dex.stats` for naming/iterating stats
- `Dex.getEffectByID` -> `Dex.conditions.getByID`
- `Dex.getType` -> `Dex.types.get`
- `Dex.data.Formats` -> `Dex.data.Rulesets`
- `Dex.formats` -> now an array `Dex.formats.all()`
- `Dex.getRuleTable` -> `Dex.formats.getRuleTable`
- `Dex.validateFormat` -> `Dex.formats.validate`
Team functions have been split off into a new `sim/teams` package:
- `Dex.packTeam` -> `Teams.pack`
- `Dex.fastUnpackTeam` -> `Teams.unpack`
- `Dex.generateTeam` -> `Teams.generate`
- `Dex.stringifyTeam` -> `Teams.export`
`Teams.export` has also been rewritten to better match how it works in client.
This implements #8178
Better subprocess query system for #7937.
I mentioned in #7937 that it should be a regular `child_process`, but
Mia's not _wrong_ that PM has some useful features that make it more
convenient than `child_process`. This change allows a
`QueryProcessManager` to easily run a query in a new child process.
This removes the need for some more casting... although I'm starting
to worry if generics are too unreadable. I suppose anyone working on
library code is likely to prefer generics to casting, and it's safer,
anyway.
- `writeUpdate` state is now stored in a global variable, so hotpatching doesn't crash it
- throttling now writes on the tail (so two throttled `writeUpdate` calls will write one update, not two)
- room settings, punishments, and helptickets are now throttled
I wrote a `forceWrap` method to support break-word wrapping in table
cells for scavengers, but apparently code blocks need it too, so I'm
moving it to Utils.
Fixes#7854
* Utils: Visualize Maps/Sets in a cleaner fashion
* OK
* Update lib/utils.ts
Co-authored-by: Guangcong Luo <guangcongluo@gmail.com>
* Update lib/utils.ts
Co-authored-by: Guangcong Luo <guangcongluo@gmail.com>
* Update lib/utils.ts
Co-authored-by: Guangcong Luo <guangcongluo@gmail.com>
Co-authored-by: Guangcong Luo <guangcongluo@gmail.com>
Building from a fresh install currently fails since #7797
The problem is that `require('sucrase')` needs to be done _after_
sucrase is installed, which is a lot harder than it sounds.
It turns out 001f98b4f2 was wrong.
When urkerab asked why it `peek` wasn't awaited:
e91c4c5260 (commitcomment-41364837)
The answer was because clearing the buffer after peeking needed to
happen synchronous: if the buffer is written to after peeking but
before the buffer is cleared, that write is lost forever.
This just goes to show, if you do something subtle enough to require
type assertions, you should probably add a comment about what's going
on.
Fixes#7605
This also removes `BattleStream#start()` which is completely useless
API complication. A better implementation would properly forward
crashes between streams (maybe `pipeTo` should do this) but as it
stands, it's not doing anything.
* 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.
We're skipping two major typescript-eslint versions, so there are a
bunch of changes here, including:
- it's catching a lot of things it didn't catch in the past, for
reasons unclear to me
- no-unused-vars has to be explicitly disabled in global-types now
- a lot of `ts-ignore`s were never necessary and have been fixed
- Crashlogger can now handle being thrown things that aren't errors.
This has never been a problem in the past, but to satisfy TypeScript
we might as well not die in a fire on the off chance someone tries to
`throw null` or something.
This adds new functions `stream.byChunk(bytes)`, `stream.byLine()` etc
which parse a `ReadStream` into an `ObjectReadStream<string>` which
can then be consumed with for-await.
Fixes#7195
`this.dex.deepClone` still exists as an alias to `Utils.deepClone` for
use in `data/`. I'll need to spend more time figuring out the correct
solution there.
Regular ReadStreams still can't; I now believe they shouldn't have a
"default" read method, and you should explicitly choose whether you
want to read "by chunks as they become available", "by chunks of a
specific line" or "by a delimiter".
So you would specifically use `stream.byLine()` or
`stream.byChunk([size])`, which would return an
`ObjectReadStream<string>`.
Inspired by #7195
Pointed out by @urkerab in e91c4c5260
I'm confused it ever worked in the past.
I also added `Symbol.asyncIterator` to make `for await` work correctly.
I'm still very annoyed by `Symbol`. Especially since the spec saw no
reason not to name the other function `next`, but calling it
`asyncIterator` instead of `[Symbol.asyncIterator] was too much of a
risk??? Complete bullshit that does nothing but break backwards
compatibility.
For some reason, my last try failed. The error just wasn't getting
caught. This is an attempt to make it not listen to the `'close'` event
if the `listen` function throws, which might work? I'll reboot to test
in Windows when I have time.
Refs #6873
This replaces the old approach with a new "clear everything except a
whitelist" approach, which should overall involve much less code and
lead to fewer bugs of the "the path changed for a module and I forgot
to update the uncache paths" variety.
I considered a lot of other approaches, but they seem to have more
flaws without any advantages in exchange for them. (We moved away
from `uncacheTree` because it only tracks the first require: there's
no way to get a full list of dependents for a module, only its first
dependent.)
