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

Get a way to represent iterable types while keeping ES5 compatiblity #23610

Closed
saschanaz opened this issue Apr 22, 2018 · 2 comments
Closed

Get a way to represent iterable types while keeping ES5 compatiblity #23610

saschanaz opened this issue Apr 22, 2018 · 2 comments
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@saschanaz
Copy link
Contributor

saschanaz commented Apr 22, 2018

TypeScript Version: 2.7.0-dev.201xxxxx

Search Terms:

Code

// Some standard web interfaces or third-party libraries support Symbol.iterator

interface SomeStandardInterface {
  method(iterable: Iterable<number>): void; // Error, no Iterable on lib.es5.d.ts
}

interface SomeThirdPartyInterface {
  [Symbol.iterator](): IterableIterator<number>; // Error, no Symbol, no IterableIterator
}

Expected behavior: We should provide a clean way to write iterable types on ES5-compatible type definition files.

Actual behavior: No such way. Some DefinitelyTyped definitions e.g. @types/node workaround this by defining Symbol.iterator and empty Iterable* interfaces.

Related Issues:

microsoft/TypeScript-DOM-lib-generator#419
#13031
#19806

@mhegazy
Copy link
Contributor

mhegazy commented Jul 17, 2018

Lib references is meant to address these issues.. unfortunately there is not an easy easy way to conditionally define a declaration. it is either there or not. at least with lib references the management of these dependencies will not involve the user.

Possibly related to #2900

@mhegazy mhegazy added the Design Limitation Constraints of the existing architecture prevent this from being fixed label Jul 17, 2018
@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed
Projects
None yet
Development

No branches or pull requests

3 participants