Bug on line 40: handling of string argument about nano-memoize HOT 5 CLOSED

@tokland Thank you. Done.

from nano-memoize.

@vsumitra Ouch! Thanks. Fixed. Must have crept in during last round of optimization. Added a unit test to prevent that happening again.

from nano-memoize.

Hi I think this was the intent, there isn't any reason to strigify a string type. plus there not way to utilized p.

var key = t === "number" || t === "boolean" || t === "string" || t === "undefined" ? a : !p ? JSON.stringify(a) : p(a);

from nano-memoize.

@vsumitra It is absolutely the case there is reason to stringify a string type. Many memoizers actually make a semantic error and treat the memoization of "1" and 1 the same. It is ironic there was a bug in nano-memozie that made an even worse error. See this article: https://codeburst.io/a-key-to-keys-when-javascript-keys-dont-match-ab44c81adc87

from nano-memoize.

Does it make sense to deprecate affected versions?

https://docs.npmjs.com/deprecating-and-undeprecating-packages-or-package-versions

from nano-memoize.