This is a long one.
So, `instanceof` in Typescript is incredibly flimsy. There's a
documented bug with what happens when you extend built-in classes, such
as Error or Array. You can read more about it here: https://github.com/Microsoft/TypeScript/wiki/FAQ#why-doesnt-extending-built-ins-like-error-array-and-map-work
However, this normally works fine. A previous commit moved some schemas
from server/ to common/, our gameSpecific UGPT settings schemas. This
caused them to break in an interesting way. For any schema recursive
with a depth greater than 1, all errors would be ignored. Why on earth
was this happening?
Well Prudence passes errors up the stack with a "return Err" -> "if
ret instanceof Err: return Err" kind of approach. This normally works
fine.
The real kicker here is that because server/ and common/ were on 0.9.7
and 0.9.8 respectively, the "Err" instance in question would actually be
erased when ran at runtime. The "if ret instance of Err" would fail,
because the Err would be from 0.9.7, not 0.9.8. This subtle difference
in file results in catastrophic damage.
In short. InstanceOf is a footgun. I hate it. Lets never do it again.
Thanks.
These are actually necessary in non-dev scenarios, as we use
ts-node/register as our loader. This expects types to exist
for our dependencies, for some reason.
I'm too tired to properly resolve this, so making @types mandatory
is my hack fix.
It's not like they add much to the build size anyway.
they're wrong, by the way. they don't analyse lockfiles but instead
analyse package.jsons. I mean, they could be correct in theory, but this
is why we have lockfiles right?
Dependabot can shut the hell up. Support PNPM. Please!
zkldi