There is a regression here for a use case that is not explicitly supported by the specification, but is supported by the Arduino IDE 1.x Serial Plotter and previous implementation of this project. That use case is the combination of a trailing delimiter and \r\n separator.

For example:

void setup() {
  Serial.begin(9600);
}
void loop() {
  for (byte value = 0; value < 4; value++) {
    for (byte variableOffset = 0; variableOffset < 3; variableOffset++) {
      Serial.print(value + variableOffset);
      Serial.print('\t');
    }
    Serial.println();
  }
  delay(100);
}

You can see how code that generates data via a for loop favors a trailing delimiter, and of course Serial.println(); is a convenient way to produce a separator.

Previously, that sketch produced 3 variables as expected:

Arduino IDE 1.8.19:

arduino-serial-plotter-webapp@eac6d39 / arduino-serial-plotter-webapp@0.1.0 / Arduino IDE 2.0.0-rc9.3:

After the change made here, it produces 4 variables:

The problem is the \r in the \r\n separator produced by Serial.println(); is being treated as a separate value. Previously, that \r was consumed by message.split(/\s/); (because it matches /\s/).

What if the separator regex is modified to include the carriage return character \r? Would that solve the problem or am I still missing something ?

const separator = "\r?\n";

Is there a particular reason why Serial.println outputs a \r\n and not \n ? We cannot have two different conventions for EOL character. Either we amend the SerialPlotter protocol or drop support for \r\n entirely.

const separator = "\r?\n";

That general approach should work. However, separator is used in the code directly as a string in addition to its use in the definition of separatorRegex, so the implementation is not quite so simple.

It will need to be something like this (not tested):

diff --git a/src/msgAggregatorWorker.ts b/src/msgAggregatorWorker.ts
index b05dddf..913915b 100644
--- a/src/msgAggregatorWorker.ts
+++ b/src/msgAggregatorWorker.ts
@@ -20,7 +20,7 @@ let buffer = "";
 let discardFirstLine = true;
 const separator = "\n";
 const delimiter = "[, \t]+"; // Serial Plotter protocol supports Comma, Space & Tab characters as delimiters
-var separatorRegex = new RegExp(`(${separator})`, "g");
+var separatorRegex = new RegExp(/(\r?\n)/, "g");
 var delimiterRegex = new RegExp(`(${delimiter})`, "g");
 
 export const parseSerialMessages = (
@@ -55,7 +55,7 @@ export const parseSerialMessages = (
   // remove the previous buffer
   buffer = "";
   // check if the last message contains the delimiter, if not, it's an incomplete string that needs to be added to the buffer
-  if (messagesAndBuffer[messagesAndBuffer.length - 1] !== separator) {
+  if (!separatorRegex.test(messagesAndBuffer[messagesAndBuffer.length - 1])) {
     buffer = messagesAndBuffer[messagesAndBuffer.length - 1];
     messagesAndBuffer.splice(-1);
   }
@@ -65,7 +65,7 @@ export const parseSerialMessages = (
 
   // for each line, explode variables
   messagesAndBuffer
-    .filter((message) => message !== separator)
+    .filter((message) => !separatorRegex.test(message))
     .forEach((message) => {
       const parsedLine: { [key: string]: number } = {};

We cannot have two different conventions for EOL character.

Why not? Inconsistency in EOL is a common situation. Not so long ago, Windows, Linux, and macOS each used a different EOL.

Is there a particular reason why Serial.println outputs a \r\n and not \n ?

No idea. It has been that way since 2006, and in the proud tradition of Arduino the person who made the change didn't bother to explain the reason:

arduino/Arduino@650c275

amend the SerialPlotter protocol

I think it is a good idea. The protocol already does specify that \r\n is supported by using Serial.println() in the all the example programs, but that is too vague. It should be stated explicitly that both are supported.

drop support for \r\n entirely.

It would be too disruptive. I'm certain the code can be made to support either without any real difficulty.

The only real challenge here is that there is no test coverage in this project, despite the fact that this code is very easy to write unit tests for.

I would like to contribute by writing the tests but I still haven't managed to setup my dev environment right.

Ideal case, I would like to debug the modifications before committing it to the repo. However, I have not been able to interface my Arduino with the standalone web-app or write a websocket script to feed values to the web-app.

Currently, I've been modifying the randomValueGenerator code manually to feed various types of messages and check its results. If you could guide me in setting this up, I would be able to contribute a lot more.

const separator = "\r?\n";

That general approach should work.

Do we have to support \r as an EOL character? In that case, the regex would be

const separator = "\r?\n?";

Do we have to support \r as an EOL character?

No. It has never been supported and I haven't seen any complaints about the lack of support (I think it is not a very common separator in Arduino sketches despite being supported in the line ending menu of Serial Plotter and Serial Monitor)

For example, this sketch:

void setup() {
  Serial.begin(9600);
}
void loop() {
  for (byte value = 0; value < 4; value++) {
    for (byte variableOffset = 0; variableOffset < 3; variableOffset++) {
      Serial.print(value + variableOffset);
      Serial.print('\t');
    }
    Serial.print('\r');
  }
  delay(100);
}

Produces no output in the plotter:

arduino-serial-plotter-webapp@0.1.0

Arduino IDE 1.8.19