CI: https://ci.nodejs.org/job/node-test-pull-request/13312/

Just a tiny doubt: the readline module works with strings only and users may get used to this (line in the listener argument is always a string). Should we demand from a user to use readable.setEncoding('utf8'); here? Maybe we can do this internally? BTW, the test does not use this call.

@vsemozhetbyt By demand you mean explicitly mention this in documentation?
I can set encoding in Interface.prototype[Symbol.asyncIterator] if you think this is a good thing to do.

@prog1dev Yes, documented advice.
Let us see what others think about it, I may be wrong.

@prog1dev I've compiled the branch and tested the slightly edited doc example code on Windows 7 x64.

1. readable.setEncoding('utf8'); seems do not affect the behavior (it is the same with it or without it).
2. It seems we have only one iteration with many lines glued together:

'use strict';

const readline = require('readline');
const fs = require('fs');

async function processLineByLine(readable) {
  // readable.setEncoding('utf8');
  const rli = readline.createInterface({
    input: readable,
    crlfDelay: Infinity
  });

  let i = 0;

  for await (const line of rli) {
    console.log(`Line ${++i}: ${line}`);
  }
}

processLineByLine(fs.createReadStream(__filename)).catch(console.error);

(node:3148) ExperimentalWarning: Interface[Symbol.asyncIterator] is an experimental feature. This feature could change at any time
Line 1: 'use strict';

const readline = require('readline');
const fs = require('fs');

async function processLineByLine(readable) {
  // readable.setEncoding('utf8');
  const rli = readline.createInterface({
    input: readable,
    crlfDelay: Infinity
  });

  let i = 0;

  for await (const line of rli) {
    console.log(`Line ${i}: ${line}`);
  }
}

processLineByLine(fs.createReadStream(__filename)).catch(console.error);

Dear reviewers, please chime in.

@mcollina Looks like no matter how much lines file has there is only one iteration of for-await-of. Here is code example:

async function print(readable) {
  readable.setEncoding('utf8');
  let data = '';
  let iterations = 0;
  for await (const k of readable) {
    data += k;
    iterations++;
  }
  console.log(data);
  console.log(iterations);
}

print(fs.createReadStream('file')).catch(console.log);

Is this behaviour intentional? Its different for readable streams in object mode
I guess its because fs.createReadStream('file').read() returns null

It seems the longing readline to be more like streams has some backing, for example #16178.

TBH, when I started to learn Node.js, using readline for a file processing seemed to me a bit hacky, with all the terminal abundant API to be ignored. And it becomes more awkward with things like crlfDelay: Infinity.

But this is a pretty basic tool for text file processing to be outsourced to more handy userland modules. And this async API would be a big step towards making readline more usable outside the CLI domain till we will have something more concise.

Is this behaviour intentional? Its different for readable streams in object mode

I'm pretty sure this is is because of internal buffering. You should try reading a different file. This is an experimental feature, and I would be surprise if it does not have bugs. Feel free to send PRs to fix those.

Ping @prog1dev

@BridgeAR Im working on this in my spare time

CI: https://ci.nodejs.org/job/node-test-pull-request/14676/

There is still a lot of logic shared between ReadableAsyncIterator and ReadlineAsyncIterator, like the entire

      this[kLastResolve] = null;
      this[kLastReject] = null;
      this[kError] = null;
      this[kEnded] = false;
      this[kLastPromise] = null;

chunk in the constructor, and also the this[kHandlePromise] function. BaseAsyncIterator could definitely have some more common code.

Let me toy with an idea.. how about we implement this on top of a PassThrough instead?
Basically we listen to the 'line' event and we write to a PassThrough with objectMode: true. Then, we use that to create the AsyncIterator. It seems we are doubling some streams machinery here.

What's the status on this?

@jasnell Stalled. Maybe later this week I can check this PassThrough idea. Also at that time I could not find an easy way to solve this #18904 (comment) issue

@prog1dev Would it be okay with you if I were to take over this PR?

@TimothyGu Sure go on

New PR opened at #23916.