some popular maintainers seem to have a habit of insisting on owning their dependency trees. even very simple established packages, they will make their own instead which is roughly the same code. is this a security thing? or what
Replies
I guess because they've got burnt by too many breaking changes, too much bloat in packages (I mean its common to see tests directory etc in npm packages), "prototype vuln" spam in security audits etc
aug 24, 2025, 5:53 pm • 1 0 • view
Im not a popular maintainer, but I’m sometimes guilty of this. A lot of times it comes from either wanting to implement something myself to learn something, or existing solutions seem super verbose for what I need, and I can probably get away with making a simpler variant for my needs
aug 24, 2025, 2:09 pm • 2 0 • view
I’m generally opposed to this if the other maintainer is available and pleasant to work with when issues arise. But I have seen many cases where that is not the case.
aug 24, 2025, 3:31 pm • 1 0 • view
in a bunch of cases i've seen, the other maintainer is active and responsive. if they're not, i think i agree its fair to fork/replicate can't think of a good reason to duplicate active, well built packages otherwise!
aug 24, 2025, 3:54 pm • 1 0 • view
Totally agree. Like qs! 😉
aug 24, 2025, 4:01 pm • 1 0 • view
hah, that is a 3rd valid case - when two packages want to follow different paths of implementation. so it makes sense to diverge the ones im talking about are near identical implementations of the same thing. only diff is the owner
aug 24, 2025, 4:18 pm • 0 0 • view