Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need a means of checking lib availability. #40462

Closed
benlesh opened this issue Sep 9, 2020 · 4 comments
Closed

Need a means of checking lib availability. #40462

benlesh opened this issue Sep 9, 2020 · 4 comments
Assignees
Labels
Question An issue which isn't directly actionable in code

Comments

@benlesh
Copy link

benlesh commented Sep 9, 2020

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.

  • Is there a way of enforcing a lib requirement on TS users of RxJS?
  • Is there a way to check to see if AsyncIterable exists and "fallback" to other types?
  • Is there a way to provide different types for different libs?

We have similar issues with trying to accurately type fromEvent, etc for both the DOM and Node.

Thanks for your time!

@benlesh
Copy link
Author

benlesh commented Sep 9, 2020

cc @DanielRosenwasser @ahejlsberg ... you might have a quick answer for this one.

@RyanCavanaugh
Copy link
Member

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

@RyanCavanaugh RyanCavanaugh added the Question An issue which isn't directly actionable in code label Sep 10, 2020
@typescript-bot
Copy link
Collaborator

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.

@benlesh
Copy link
Author

benlesh commented Sep 15, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Development

No branches or pull requests

4 participants