Description
Hi,
From https://github.com/dylang/shortid/blob/master/README.md#shortid---
Can generate any number of ids without duplicates, even millions per day.
I've been trying to figure out how shortid guarantees uniqueness, and I've come to the conclusion that in fact it doesn't at all (any more).
The way this module worked as at https://github.com/dylang/shortid/tree/2.2.8/lib is that it encoded a number of variables (version, worker, seconds offset, counter), mixing in some randomness so that the ID wasn't guessable - however the original data was still hidden between those random bits, and it could be decoded by bit-masking. Given different input the ID was therefore guaranteed to be different (at least subject to #105).
Since 0e9c560 that's all broken. The number to be "encoded" now only influences the string length, but doesn't actually make it into the string at all
Line 14 in 1403944
The string is actually completely random, and has at least as much chance of collision as any random string of its length and alphabet. None of version, worker ID, or time have any impact whatsoever on what is generated.
Please tell me I'm wrong!
Edit: I notice @ai has been closing issues with the assertion that this package is deprecated, but in anticipation of that I'll just note -
- This project is not marked as deprecated on either NPM or github. It still has almost 1M downloads per week and ~80k dependent projects. If it's deprecated that needs more visibility.
- It's had a fairly massive behaviour change that means it won't do what people expect it to do, and this was changed in a semver patch release. The readme still promises the old functionality, even though there have been 5 further new versions since.
nanoid, though it seems good at what it does, is not a like-for-like replacement - that's a random generator, not a unique generator.
It seems to me like when maintenance changed hands after 2.2.8 there might've been an honest misunderstanding about what this package did / was meant to do / how it worked.