Using IteratorResult errors unless you build with --ES6

[benlesh]

This doesn't make any sense, it's just an interface. I should be able to use it wherever I want.

export default function() : IteratorResult<any> {
    return { done: true };
}

tsc Test.ts --modules "commonjs"

and I get error TS2304: Cannot find name 'IteratorResult'.

It will build without errors if I use --target es6, but I'm trying to target multiple things, CJS, AMD, ES6 and ES5 globals.

[benlesh]

The temporary solution was to add a .d.ts file under a child the typings directory with the definition in it:

/typings/fixes/fixes.d.ts

interface IteratorResult<T> {
  done: boolean;
  value?: T
}

[danquirk]

You can use the interface wherever you want when it's defined, hence your workaround. With --target ES6 you get the lib.d.ts that contains the definition for IteratorResult, when you don't, you get the ES5 lib which doesn't say anything about Iterators. We have another issue somewhere with some discussion of breaking up the association between ES target and the lib.d.ts version.

[mhegazy]

As @danquirk mentioned, the definition for the interface is in lib.es6.d.ts, along with other interface definitions in the ES6 spec. The reason why they are split in a separate file, is to avoid confusion when using new ES6 interfaces on current engines that do not support them. From the compiler perspective, all what is needed is the type declarations. you can include the interface definitions by themselves, like you mentioned, or include lib.es6.d.ts as a whole either on the command line or by a /// reference. we are also looking in adding a --lib flag to allow you to explicitly require a specific library file (#2953 (comment)).

[benlesh]

it seems like, for the majority of interfaces at least, it shouldn't matter that I'm targeting ES6 or ES5. I'm just saying "I expect this contract for this object". I understand that certain declarations won't be in place, but interfaces seem legit to me.

[mhegazy]

I agree interfaces are fine. it is just untangling what is fine and what is not is a bit.. manual. should Promise be defined or not for instance, or just put the interface but not the constructor declaration... so we lumped them all based on the version of the language they came from.

[danquirk]

It matters in the sense that your completion lists are now filled with a mix of things that will and won't work, and the compiler is not giving an error for things that don't actually exist where you'll be running your code. Yes they're just types so there's no missing runtime code but if you're writing a bunch of TS against the Iterator concept but then executing on ES5 you're probably not getting the experience you want unless you're aware of the distinction. By default we're trying to lead people down the happy path where the compiler is aware of your target runtime and doesn't provide things which don't exist there. Obviously some folks like yourself are targeting a variety of runtimes (with and without a variety of polyfills) which is why we may need to decouple the --target flag and the lib version it entails.

[benlesh]

By default we're trying to lead people down the happy path where the compiler is aware of your target runtime and doesn't provide things which don't exist there.

But interfaces with simple types do exist...

interface IteratorResult<T> {
  value?:T;
  done:boolean
}

And { done: true } exists in all versions of JavaScript.

[danquirk]

But all the things you are likely to want to do with an Iterator require ES6 unless you have a post-build step that transpiles for you. Since that post-build step doesn't exist by default and we can't tell whether it's there we're trying not to lead someone down a path where they use a bunch of Iterator based APIs when targeting ES5.

[benlesh]

Any interface can be implemented and returned in plain es5. As I'm sure you're totally aware, this is one of the principles on which transpilers are built. If I want to return a type that doesn't exist in my target, then the onus is on me to polyfill that type.

tsc could warn me, maybe, but their is no reason it should error. All that does is cause me to add the interface myself, or worse, return type any.

[benlesh]

Incidentally, I've just added the interface myself to each file I need it in. So I've worked around this sort of unfriendly feature. I haven't closed this only because I thought you might want to track the concern.

[mhegazy]

We are looking into allowing --lib flag to allow for using different version of the library.