3 ms·
If you look at the library (and many of his other 100+), then the code itself is so simple that it barely counts as a library. It's 60 lines where the only logi
by ljm 6y ago
If you look at the library (and many of his other 100+), then the code itself is so simple that it barely counts as a library. It's 60 lines where the only logic is to type-check for a string or a number.
Mind, it's not to the same level as this guy: https://github.com/jonschlinkert https://github.com/jonschlinkert
Chances are it's just found itself as a dependency of a dependency, rather than being used directly. Not to shit on either of them, but they both 'maintain' a large amount of trivial packages that any language with a sensible standard library wouldn't require.
- whoisthemachine 6y agoI don't think that takes away from it. He's also the author of remarkable, which is a ... remarkable library.
- feross 6y agoYou're downplaying my `safe-buffer` library without understanding the reasons that it exists. The Buffer security issues that Mathias Buus and I uncovered led to the deprecation of `new Buffer()` in Node.js and the creation of the `Buffer.from()` and `Buffer.alloc()` APIs. There is an explanation here: https://github.com/feross/safe-buffer#why-is-buffer-unsafe https://github.com/feross/safe-buffer#why-is-buffer-unsafe I created `safe-buffer` as a demonstration of how the API could be fixed to be safe. Then, the ecosystem adopted `safe-buffer` as a polyfill to get that safety even before `Buffer.from()` and `Buffer.alloc()` were included in Node.js. And to this day it continues to be used to provide safety in older versions of Node.js which lack the newer APIs. tldr; We fixed Node.js and made it safe for you. But, by all means, feel free to continue mocking me and the volunteer work I've done for the community :/