"Simple JS can't have unexpected security/performance pitfalls".
Hah.
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
I know this isn't directly related, however one of the vulnerabilities is prototype pollution [0], a deceptively simple technique that I think so many apps are vulnerable to. It goes like the following:
- Get an application to serialize or take `__proto__`, `constructor` or `prototype` as an input so it's a key on a JS Object
- Serialize its value to something nasty, like `'{"auth": {"name": "user", "password": "pwd"}, "message": { "text": "", "__proto__": {"canDelete": true}}}'` [1]
This high jacks the prototype of the object and adding those specified properties. If you do things like deep merging of objects on data, you are susceptible to this without the proper guards in hydration / rehydration. The mitigation is simple: don't allow objects to have `constructor`, `prototype`, or `__proto__`. You can delete them by customizing JSON.parse (by passing a reviver [2]) or using something like `mergeWith` to skip these keys
A similar vulnerability exists with `constructor` and `prototype` as well [3]
[0]: https://portswigger.net/daily-swig/prototype-pollution-the-d...
[1]: https://github.com/Kirill89/prototype-pollution-explained
[2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[3]: https://shieldfy.io/security-wiki/prototype-pollution/introd...
A prototype can only be modified by code that is actually being run. If you can get someone else's application to run code under your control, you've already won.
It requires some knowledge of the inner workings of the system (in the above, you'd have to know that the auth provider checks for a cached `isAdmin` prop on some object before executing the authentication routine to generate it). But if your system is designed to only be secure if no-one knows the inner workings, you're probably owned anyways.
https://archive.is/l4svG (jwz link, so archive.is)
Lodash as an npm module is out of control, file-size wise, and I'm not sure I'm really getting anything for it, other than once a year having to make sure we don't have ten copies of it that can't be deduped (Currently it's occupying 29MB of disk space on my production machines)
As I remember it, Lodash biggest difference was its modular approach also, not all about performance. Lodash also addressed some inconsistencies in Underscore.js.
For many others, the OP's use is common and correct—in a lot of areas.
"They ripped me off" is very prevalent in English speaking countries too, outside of tech.
Having the (almost) same API surface as another MIT library is hardly a "ripoff" but a re-implementation.
Edit: since new evidence has come forward (https://news.ycombinator.com/item?id=27275379) I think we can all agree that Lodash is a fork of Underscore.js, nothing more and nothing else.
https://github.com/lodash/lodash/commits/0.1.0?after=e0971cd...
If they were giving "no credit at all", they would be in violation of the MIT license.
Ok, does that make forks who don't mention where they forked from rips? Huge leap in logic.
> Why should I need to dig into the Git history to find out the creative origin of Lodash?
Well, if you're interested in the origin you either look for information available in threads like this, where other people dig or you dig yourself. Not sure what the problem is. Someone published a library under MIT, another person forked that library and created a new one, also under MIT, and somehow the fork is now a rip? Give me a break
> Based on Underscore.js, copyright Jeremy Ashkenas, DocumentCloud and Investigative Reporters & Editors <http://underscorejs.org/>
They've given precisely as much attribution as is required.
I have no qualms with forks or reimplementations (ie. Android - Java.) I actively support the paradigm.
But in this case, it's pretty shitty to try to erase all evidence of said inspiration. Most forks and reimplementations don't do that. They pay homage to their origin with at least a shout out.
After some digging, it seems like the Lodash website stopped mentioning Underscore.js around 2015 sometime, but even before that, it never had "evidence of said inspiration" as claimed by you.
Here are the versions I looked at:
- https://web.archive.org/web/20120826202523/http://lodash.com...
- https://web.archive.org/web/20130502014523/http://lodash.com...
- https://web.archive.org/web/20140517192947/http://lodash.com...
- https://web.archive.org/web/20150513014815/https://lodash.co...
- https://web.archive.org/web/20160803063412/https://lodash.co...
- https://web.archive.org/web/20170830163720/https://lodash.co...
- https://web.archive.org/web/20180703043557/https://lodash.co...
- https://web.archive.org/web/20190803030353/https://lodash.co...
- https://web.archive.org/web/20200615092636/http://lodash.com...
- https://web.archive.org/web/20210314233141/https://lodash.co...
> A drop-in replacement\* for Underscore.js
You are right though, my memory failed me. No mention of forking.. Shameless!
Inside Macintosh > Macintosh Human Interface Guidelines > Part 2 - The Interface Elements > Chapter 4 - Menus > Tear-Off Menus and Palettes
http://mirror.informatimago.com/next/developer.apple.com/doc...
http://mirror.informatimago.com/next/developer.apple.com/doc...
>A tear-off menu allows users to move a menu around the screen like a window. Tear-off menus save desktop space because the user can place them on top of a document or move them to a convenient position. If you implement a tear-off menu rather than a fixed palette in a window, you allow the user to have a larger workspace in document windows. Users can also choose to leave the menu in the menu bar, or tear it off and close it when necessary. Tear-off menus give the user more flexibility than fixed palettes do.
The library is free and worked on by maintainers in a spare time from main duties (not talking here about lodash specifically).
Maintainers don't own you any support nor obliged to work the way you may think they should.
I would say that it's great that we have many tools and should give more respect to maintainers which basically save you a ton of resources and maximum they ask for is to follow the established processes.
Any issue was immediately closed and only closed issues would be reopened if enough people gave said closed issue enough thumbs up (and "enough" wasn't even defined). And of course, this process wasn't explained anywhere except in replies to closed issues.
The obvious problem with this was that no issues were ever acted upon ever because no one ever looked at closed issues, because why would they?
I had created a proposal for a new function to be added that was and still is sorely missing. After it was closed and a long discussion ensued between many devs, I gave up and a year later I simply replied that I retract the proposal due to the ridiculous policy of actively being hostile to users. The maintainer deleted the whole issue and along with it all proof of their hostility and hypocrisy.
It was then that I decided I would boycott lodash and simply use better libraries in my projects now like Ramda, which is actually OSS. Looks like lodash is now no longer maintained and has hundreds of tickets open after the hostile maintainer (and it's not hard to guess who from looking at the commit counts) appears to have stopped maintaining it.
Funny how that works, closing tickets constantly ensures no one will want to help, and then the maintainers feel overwhelmed because they are doing it alone.
Basically closing issues is an awful practice that helps no one, as you say.