I'm facing an issue with RxJS where we've moved to support AsyncIterable, but if a user compiles a project that uses RxJS with TypeScript and a lib that is less than ES2018, then the type inference is all messed up because AsyncIterable doesn't exist.
lib requirement on TS users of RxJS?AsyncIterable exists and "fallback" to other types?libs?We have similar issues with trying to accurately type fromEvent, etc for both the DOM and Node.
Thanks for your time!
cc @DanielRosenwasser @ahejlsberg ... you might have a quick answer for this one.
Is there a way of enforcing a lib requirement on TS users of RxJS?
It's not ideal, but you can write /// <reference lib="esnext.asynciterable" /> in your .d.ts to force that type definition to be in scope. The caveat is that this will surprise your users who set target: es5 because they'll start seeing ESNext types
This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow.
@RyanCavanaugh would we have to add that to the .d.ts manually?
It's definitely not ideal. Ideally we'd be able to change what we're doing based off of what lib they're using. This is a problem we have in other places too.
In RxJS, we can convert iterables, promises, async iterables, et al, to observables. If they don't support async iterables, ideally we wouldn't have that in the union type we're using. I guess I was looking for something like:
type ObservableInput<T> = Observable<T> | Promise<T> | Iterable<T> | (IsDefined<AsyncIterable> ? AsyncIterable<T> : never)
... or _something_. Haha. I have no idea how it would work. It seems like we can already do so much meta programming in the type system that it's _almost_ possible.