This field test was against Node.js.
The issue was Node.js #22448:
https://github.com/nodejs/node/issues/22448
The public PR is here:
https://github.com/nodejs/node/pull/63789
The reported problem involved readline splitting input on Unicode line separators.
By default, Node’s readline behavior treats \u2028 and \u2029 as line separators.
That can be useful for general text handling, but it creates a problem for formats like JSONL, where a record may contain those Unicode characters as part of the actual line content.
The useful diagnostic boundary was:
readline line parsing → Unicode separator handling → record-oriented input integrity
That matters because readline is not just a convenience API.
It is often used as a boundary between raw input and structured record processing.
If readline splits on characters that a file format treats as valid content, the parser can break the caller’s record boundary before the application ever sees the full line.
In plain English:
the input stream still contains one logical record, but readline can split it into multiple lines too early
That is a boundary failure between text-line convenience behavior and record-oriented input truth.
The repair is intentionally narrow.
It does not change the default behavior.
It does not remove Unicode line separator support.
It adds an option:
unicodeLineSeparators
The default remains true, so existing behavior is preserved.
When set to false, readline.createInterface() and readlinePromises.createInterface() split only on CR, LF, and CRLF. In that mode, \u2028 and \u2029 remain inside the line content.
That gives callers a clear way to preserve record-oriented input without breaking existing users who rely on the current behavior.
The patch updates the readline implementation, the public API docs, and regression coverage.
Validation passed for:
- Node build
- focused readline line-separator test
- Node test runner against the focused test
- JavaScript lint on touched files
- Markdown lint on touched docs
- diff hygiene
Field Test #017
- Project: Node.js
- Issue type: readline Unicode line separator behavior
- Boundary: text line parsing vs record-oriented input integrity
- Result: public PR opened with API option, docs, and regression test
- Status: PR open; ready for review
This field test matters because it sits inside a foundational runtime API.
The bug is not a web app failure.
It is not a framework-specific edge case.
It is a runtime boundary that affects how programs consume input.
A caller may be reading JSONL, logs, streamed records, or other line-oriented data. If the runtime splits the input before the application’s format boundary is preserved, the application receives a shape of data that is no longer true to the source.
The important part of the repair is that it does not force one interpretation on everyone.
Instead, it makes the boundary explicit.
Default behavior stays the same.
Record-oriented callers get a way to opt into stricter CR/LF-only line splitting.
That is the kind of repair Scarab is built to surface:
not a broad rewrite,
not a behavioral break,
but a narrow boundary correction that lets the runtime preserve the truth the caller actually depends on.
Top comments (0)