I think this needs another test that includes a sarif file without line numbers.

The fingerprinting2.input.sarif test file was already missing line numbers, so that's showing the new behaviour of omitting the fingerprints (see change in expected output). I'm not sure if that was testing any other behaviour that is now being missed, it didn't seem to be doing anything particularly different from the first test case to me.

Ah...yes. Was re yon my phone and didn't see the whole file.

What is 65535?

It was being appended at the end of the files when computing their fingerprint in the existing code. I don't know quite what its purpose is, but in the interest of keeping the fingerprints the same I think it makes sense to keep it there.

Yeah, it doesn't seem like a reasonable thing to change given that it would affect the hashes. It might be best to move it into a constant so it doesn't remain a magic number in that case.

Be careful about mixing async-await and callback patterns. Error handling gets tricky because thrown errors don't necessarily correlate to promise rejections.

In this case, this could be rewritten entirely in async-await like so:

const readStream = fs.createReadStream(filepath, "utf8");

for await (const chunk of readStream) {
  // Handle the chunk
}

processCharacter(65535);

Any potential errors would be caught as normal because synchronous functions would throw and asynchronous functions would be rejected (because of the await).

Since this appears to be used for iterating over lines, the Readline API could be useful for consuming the stream:

const reader = readline.createInterface({
  input: fs.createReadStream(filepath, "utf8")
});

for await (const line of reader) {
  // Handle the line
}

processCharacter(65535);

Thanks for the suggestions! I've applied your first one in #550, it is indeed nicer than what I wrote. The second one doesn't quite fit our use case nicely because we actually want the new lines in the hash.

[…] we actually want the new lines in the hash.

Good catch. I figured it would contain the line endings since you're able to redirect the stream directly to {stdout|stderr}.write but apparently it doesn't. 🤔