Devansh Jethmalani

Yep it's possible but you need none of that, not even the tuple inference trick. The thing is these existing types are unnecessarily complex, in particular the `bindAll` type (and...

Opened #45. It turns out that this approach has one downside when supporting untyped events ("supporting" meaning fallbacking to `Event` for events that were not found on the target as...

(I don't have any opinions, just giving a heads up that this PR as it is will be a breaking change)

@andywer Hi Andy! I completely understand that it's tempting to support typed-emitter in rxjs-from-emitter so that it becomes one-stop solution to deal with emitters and fromEvent especially when typed-emitter is...

Thanks! Yeah, alternatively you can still keep the package typedef only by exporting the type instead of the implementation so user would use it like this: ```typescript import { fromEvent...

Yeah that could work didn't think about that, would be a much better solution also!

fwiw afaict this makes you unable to write [inline scripts in NextJS](https://github.com/vercel/next.js/issues/26240).

Btw one can write a class equivalent of this too... ```ts interface F { a: unknown , b: (a: this["a"]) => unknown } new class implements F { a =...

👀 I'm happy txstate is trailing the path for better types :P (nitpick: I call them "Self-Reconstructing" type just saying so that we don't end up with names like "Typestate"...

@cassiozen I want to provide a safe version in v1.0.0 itself. Which one of the two options you like? And what should we name it? "safe" is very ambiguous.