Feature request: Flag to opt into higher quality hashing.

[LukeAbby]

I was fixing this error:

[9, 49, 1, "Type \'WordTreeEntry\' does not satisfy the constraint \'{ [x string] never; [x number] never; [leaves] never; }\'.\\n  Property \'[StringTree.leaves]\' is missing in type \'WordTreeEntry\' but required in type \'{ [x string] never; [x number] never; [leaves] never; }\'.", "177612"]

And I accidentally introduced this error:

[15, 101, 1, "Cannot find name \'voi\'.", "177612"]

However Betterer didn't warn me because they just happened to have the same hash. It looks like you use djb2a which is non-cryptographic which probably accounts for this collision because the purported hash space is 32-bits so a collision occurring when I only had 4 errors in that file before should have been 4/2^32 or a ~0.000_000_09% chance. That should be a worse than a 1 in a billion chance.

This probability is accurate because this can be modeled as a "draw without replacement" and while of course many people have updated their .betterer.results file before I would be inclined to say it's not been in the billions.

I would welcome a flag to opt into a cryptographic or at least higher resolution and quality hash.

[phenomnomnominal]

Wow, thanks for the report, and thanks for working out the chances of that happening, that's wild! Here I was thinking 1 in a billion would be good enough, but I guess not. I'm not opposed to a flag at all, but maybe it is just better to use a better hash. I originally did djb2a because it's pretty quick, but maybe the per doesn't matter so much in the scheme of things. I'll do a bit of research and figure something out.

In the meantime it's probably a pretty simple https://www.npmjs.com/package/patch-package to fix that, or even a package.json resolution if you can find another package that has a hash function as the default export.

[LukeAbby]

For what it's worth it's probably explainable through either the birthday paradox (the hash function is good but the chance of collision is unintuitively high because of the number of pairs in a real world scenario) or just the hash function being non-cryptographic and therefore being more likely to collide nearly by definition.

Glad to see this being taken seriously though!