Error message on use of async iterators in nodeJS 10 streams misleading

[BurtHarris]

TypeScript Version: [email protected]

Search Terms: async iterator ES2018

Code

import { PassThrough } from "stream";  // with  @types/[email protected]
// Compiled with --target ES2018.

const stream = new PassThrough();
stream.write( Buffer.from([0,1,2,3]));

async function doIt( )  {
    var buf : Buffer;
    for await (  buf of stream ) {
        console.trace('>>>buf ',  buf);
    }
}

doIt();

Expected behavior:

No error message. Fallback code generation or polyfill based Symbol.asyncIterator.

Actual behavior:

Message: message index.ts:12:25 - error TS2519: An async iterator must have a 'next()' method.

This error message is wrong, because the code generated (__asyncValues) depends on [Symbol.asyncIterator] rather than next() on the stream.

Playground Link: Playground does not behave the same, it currently generates different code that actually does depend on a next() method, so this link is not particularly useful.

Related Issues: #20463, the fix here might make the message go away, just as using --target ESNEXT does, but I think that misses the point. Shouldn't the --target option control the choice of generated language, and not what input syntax is permitted?

This currently happens for If --target ES2015, ES2016, ES2017, or ES2018, but not ESNEXT. If --target ES5, a different error is generated, requiring a Promise constructor.

I'm hoping we should be able to polyfill async iterators into any implementation support promises and symbols.,

Note: the of the @types/[email protected] version of index.d.ts I'm using does declare that stream has a [Symbol.asyncIterator] method. If it lacked that, then the message displayed might make sense, but as the generated code never even uses next() method, the message is still confusing..

[ghost]

It looks like Stream.prototype[Symbol.asyncIterator] returns a AsyncIterableIterator which is not defined under the default lib setting for es2018. Node provides a stub declaration, but that doesn't have next() in it. Using --target es2018 --lib esnext works, but if we support compiling to async iterators presumably we should have the interface available too.

[rbuckton]

This is analogous to defining a custom default lib and not filling in the type for Promise and getting errors for await not working.

We should be able to resolve this by changing the node definitions to use lib references once typesVersions support is rolled out to DefinitelyTyped.

[rbuckton]

This should be resolved now that the NodeJS definitions on DefinitelyTyped are using "typesVersions" and lib references.