Since this is part of a rule, it seems like this typo should be causing a bug. Can you please create a test that shows the bug is fixed?

Isn't it hard to show an error that is fixed with a test? i can only assume that the tests still work to show that all intended functionality is still there. That being said, this correction is correct, according to the Node.js documentation on buffer (https://nodejs.org/api/buffer.html#bufreaddoublebeoffset). There is no readDoubleL, but there should definitly be a readDoubleLE. I believe this one should be merged right away, as it removes 1 false positive and 1 false negative.

You should be able to write a test that fails without this fix and passes when the fix is applied. Without doing so, we can’t really know if there was a problem with this code or if the proposed fix actually solves a problem.

I can write a test, but since the fix is here it would just pass. Still, i don't agree that we can't really know if it solves a problem, since the string is checked against the official node api's buffer's member expression, and there is no readDoubleL but readDoubleLE is missing. And the tests still pass, so the change should have no breaking impact.

What I’m describing is common practice in programming. Write a test that fails to makes the bug obvious and then write some code to make the test pass.

In this case, the rule checks the array here:
https://github.com/nodesecurity/eslint-plugin-security/blob/208019bad4f70a142ab1f0ea7238c37cb70d1a5a/rules/detect-buffer-noassert.js#L62

So you should write a test that checks buf.readDoubleLE(0, true) was not flagged as invalid before your fix and is flagged as invalid after your fix.

This is the way we prevent regressions.

In the interest of time I fixed this myself.