readline: processing \u2028 and \u2029

Not sure if we should fix, document, or ignore this and if it has been discussed, so to be on the safe side.

Currently, \u2028 and \u2029 are considered as line breaks by JavaScript RegExps, while they are ignored by the readline:

'use strict';

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

const str = '123\n456\r123\u{2028}456\u{2029}789';

console.log(str.split(/^/mu));

fs.writeFileSync('readline-test.txt', str, 'utf8');

const rl = readline.createInterface({
  input: fs.createReadStream('readline-test.txt', 'utf8'),
  crlfDelay: Infinity,
});

rl.on('line', console.log);

Feel free to close if this is a wontfix.

I think consistency with JS RegExps is a good argument to do this.

I agree with changing this for consistency.

If we want to support this, should it also be an opt-in as is for regular expressions?

If we want to support this, should it also be an opt-in as is for regular expressions?

Are they actually opt-in in regular expressions though?

To me it looks like they always get interpreted as newlines (with or without the u flag):
$screenshot of running node -e 'console.log("123\n456\r789\u{2028}ABC\u{2029}DEF".split(/^/m));' resulting in [ '123\n', '456\r', '789 ', 'ABC ', 'DEF' ]$

@dario-piotrowicz

Is this issue still relevant? It appears to have been resolved by @dario-piotrowicz in a42bca5

Maybe it would be possible to add a new option to createInterface that allows you to specify a line separator? I'd like to be able to use readline to stream jsonl files, but are written with \u2028 in string values which gets separated and is no longer JSON.parseable

Happy to make a PR if this sounds reasonable

Please forgive me for butting in so late in the game, but I have just encountered this for the first time:
I would propose that consistency with regular expressions is not the choice to make here.
As someone who is using readline to parse text files (in this case .jsonl), I see a very sharp distinction between formatting, where the various U+2028, U+2029, RTL/LTR OVERRIDE, etc... characters are relevant, and actual "system line separation" (CR or CRLF (and perhaps some old systems still exist with LF?)) which is IMHO an almost-binary boundary. Adding new newline conventions only adds noise to the already fragmented CR/CRLF/LF situation.
At most, I would add support for splitting on U+2028 and the like as an opt-in, not as the convention. I realize that in the current situation the train has already left the station, so can we please have an opt-out?

This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.

Navigation Menu

Repository navigation

readline: processing \u2028 and \u2029 #22448

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

readline: processing \u2028 and \u2029 #22448

Description

Activity

addaleax commented on Aug 28, 2018

apapirovski commented on Aug 28, 2018

BridgeAR commented on Jan 11, 2020

dario-piotrowicz commented on Mar 22, 2025

DemianParkhomenko commented on Feb 14, 2026

elimelt commented on Apr 17, 2026

ameiri commented on Jun 5, 2026

github-actions commented on Sep 4, 2026

github-actions commented on Oct 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions