Except when it's a license violation or in something that ends up having a security vulnerability.

>Except when it's a license violation or in something that ends up having a security vulnerability.

What's more secure isn't so simple. If you vendor something with a vulnerability then it wont be patched. But vendoring may also mean you took the 2% of the library you need and not the 98% which reduces the surface area for vulnerabilities. And it can cut the other way - you may update a package that was previously good and is now vulnerable (regressions, supply chain attacks).

There is a balance that must be struck, and I think LLM's strike a better balance than people do. Dependencies are a convenience with a cost and LLM's can trivially copy or re-implement things that we cant.

	▲	packetlost an hour ago \| parent [-]
		> But vendoring may also mean you took the 2% of the library you need and not the 98% which reduces the surface area for vulnerabilities If you aren't using a library function you're not vulnerable to exploits in that code: unused but imported code is inert (possible usable as a gadget if you're vulnerable elsewhere, but at that point you're screwed anyways) and most compilers/runtimes completely eliminate it. > you may update a package that was previously good and is now vulnerable (regressions, supply chain attacks) There are better mitigations to this than not using a library. You still completely ignore the license violations.