Semi related to this I think a good way to avoid back doors in open source software is to have as few dependencies as possible. So I appreciate that this is a thing.
Maybe it avoids backdoors but it also avoids the maturity and security of using shared implementations for common tasks in favour of half-assed implementations in your own code.
Just because someone else wrote it, doesn’t mean it’s a good implementation, or worth bringing its pile or dependencies into your project.
Speaking specifically about npm: A ton of packages used as dependencies for a million different things have very loose quality control, some even merge community PRs straight to release without checking the code in any way. More often than not I have run into packages maintained by people with no connection to the original dev and don’t even know how its code actually works.
I remember a couple years ago I needed to read zip64 files so I picked up the zip file definition and implemented the read operation for it in the package we were using for zips. I only implemented a very small subset of the format to strictly solve my problem. I opened a pr to them saying “here’s some quickstart of you plan to add full support for zip64” - next time I checked they has merged my pr as if was and now were having folks registering issues for incomplete zip64 support.
