Interesting that uFuzzy depends on regexps. Python's regex library can handle fuzzy matching (up to a given number of insert/delete/substitutions) - if JavaScript had that, it would be a relatively simple change.
e.g.
/^cat$/ will match cat
/^ca[tr]$/ will match cat and car
/^ca\w$/ will match any 3 letter word with 'ca' prefix. (any substitution for third letter)
/^\w\w\w$/ will allow alterations for any letter, making it useless.
you can make a more complex regex that allows a single substitution in any char position
/^(?:ca\w|c\wt|\wat)$/
but this gets out of hand very quickly, especially with possible insertions, deletions, transpositions, etc.
Anyway, not being a hater (as that other commenter suggested), if you could add support for this (even if it's limited, one or two typos at most) you will blow all other libs out of the way since what you have now is already quite good :D
of course if you have specific known/common mistakes, it could be useful to only consider those. for example, spelling errors are less common at the start of words. and keyboard letter proximity limits which mistakes are likely.
At least on mobile, I find I make just as many first letter mistakes by hitting the wrong "key" on the on-screen keyboard, as I do in any other position of the word. Very annoyingly the predictive text engine assumes like you mention and it takes a lot for it to consider the first letter being wrong.
This would help a lot I think.
When I'm on mobile, the most common error is "keyboard offset error", where I hit a "key" next to the one I intended. So it's not completely arbitrary, and it only happens once or twice in 99% of the cases.
On a physical keyboard this also happens, but the more likely error is synchronization error, where I hit a left-hand key before a right-hand key or vice versa, the classic teh vs the. Again usually only a single such error per word and not arbitrary.
Finally there's also the common case of simply missing a letter. Again, limited and not arbitrary.
So at least for my sake, anything that can handle the above errors would go a long way.
The regex library builds the NFA, so it probably bakes the fuzzy stuff into the NFA itself rather than changing the pattern.
Another option is something like word2vec where you cluster words of similar meaning together, as a bonus this usually handles typos as well. Not really in scope for your library, but I find it cool!