Feature/#23 handle carriage returns

[X1Vi]

Fixes #23
I have added CR Pattern handling.
We are using a boolean to enable this functionality and check for Window, Linux and MacOS.

If False then we execute then normal flow instead of the True flow

I am assuming \n is for linux and macOS, \r\n is for windows and \r is for crdata.

I have added some tests for this as well that checks basic functionality.

I ran npm test and all test were passing

[X1Vi]

@extrabacon Are you reviewing this ?

[StantonMatt]

Thanks for the PR. I checked this locally and npm test passes for me (45 passing).

One edge case seems worth covering before merge: when handleCarriageReturn is enabled and a normal Windows \r\n newline is split across stream chunks, NewlineTransformer currently treats the trailing \r as a standalone carriage-return update. That means the line is emitted as crdata instead of message.

I reproduced it directly against this branch:

const { NewlineTransformer } = require("./index.ts");
const transformer = new NewlineTransformer(true);
const data = [];
const cr = [];
transformer.on("data", chunk => data.push(String(chunk)));
transformer.on("cr", chunk => cr.push(String(chunk)));
transformer.write("first\r");
transformer.write("\nsecond\n");
transformer.end();
transformer.on("end", () => console.log({ data, cr }));

Current output is effectively:

{ data: ["second"], cr: ["first"] }

For a split \r\n, I would expect first to remain a normal newline-delimited message, not a crdata update. A focused transformer test for that chunk-boundary case would lock this down.