ASCII-only

@user tons of deno packages support node thanks to an official build tool

i guess you could do a quick search in issues for some of the more obscure features (if any) if there are any they still havent implemented or something

@hyper-neutrino deno should be very stable nowadays, discordeno... is full-featured enough for me but i dont use anywhere near all of discord's API so i cant really say whether itll cover your usecase

@lyxal yeah, it's mostly because i figured I'm not very active of a contributor anymore... like i don't mind contributing but i'm not active here enough to know what needs doing

this is why all the cool kids use discordeno

but i mean... if it ain't broke anymore, don't fix it, lol

yeah... it's weird that djs issues didn't mention anything about this though

for performance? probably .bind(this), by a very narrow margin

i'm pretty sure djs has had these typings for years though

huge thonk

but i don't feel like that's possible because, while they're both the only callbacks with != 1 argument... both of them have two arguments

this error does sometimes happen when the second argument is used as the discriminator

cuz it's definitely working for all the other .on which is kinda weird

@Bbrk24 not sure, unfortunately i don't have the typings for discord.js memorized - what does the type parameter get inferred as?

if they don't know about Object#constructor i suspect they wouldn't even think of using constructor as a key

well

like, no offense but that's a lot of hoops you'd have to jump through to intentionally trigger that error

@Bbrk24 that's fair but who in their right mind would be explicitly accessing the field called constructor with a literal-typed string

function coerceSetting<T extends keyof IServerSettings>(
  key: T,
  value: string
): IServerSettings[T] | undefined
function coerceSetting(key: keyof IServerSettings, value: string): IServerSettings[keyof IServerSettings] | undefined {
}

that's fair... but it's not like constructor?: never does much for type safety... does it?

@Bbrk24 hm?

@Bbrk24 this is trivially solvable (although not type-safe) by using a single overload

yeah typescript kinda doesn't do inheritance in general... apart from what it must, of course (class extends foo)

for other cases yet ("key1" | "key2" it will type-error anyway)

for many other cases (e.g. string), it's impossible to check them all

@Bbrk24 beacuse typescript doesn't go through each possible type parameter because in many (if not most) cases, it's too slow

@Bbrk24 it doesn't let you, yes, but there is no way to mark a type as not having extra keys in typescript

@ASCII-only wait wrong type, that's the type for Object.entries...

case and point

hence, they are absolutely needed

@Bbrk24 also not type safe.

@Bbrk24 yes, because this is not type safe.

if a has literally any property at all then 'foo' in x works perfectly

@ASCII-only although this is more because of {} acting funny than anything

@Bbrk24 nope, they can't.

i have a suspicion the reason why it does this is because it's not of type A | B

well

assuming B has the key 'key' and A doesn't

@Bbrk24 no, because if it's already an A | B it narrows it to B.

(if ('key' in obj))

it's easy enough to check whether an object is B

i mean

@Bbrk24 this is why module augmentation is a thing in ts.

> Emit more compliant, but verbose and less performant JavaScript for iteration.

fun fact: the flag description even says why it's not the default behavior

link to playground

@Bbrk24 yes, and downlevelIteration is the flag that uses the correct behavior...

@Bbrk24 downlevelIteration moment

yeah ... is what, ES6?