[ben0x539]

Really, what's the qualitative difference between reaching for a utility function that someone else already wrote within your project and reaching for a package that someone else already published within your ecosystem? They're obviously not the same thing but are they so far apart that you can't wrap your head around it wanting to treat them the same, given sufficiently advanced tooling?

[amiga386]

The utility function just has to fit your use case, and can be easily refactored as it lives in a local context.

The package has to have a public API, meet millions of different people's use cases, and any change to the API will cause millions of man-hours of useless work... and yet if it's a poorly designed API, it might cause millions of sub-optimal programs.

Every project has a StringUtils file. But every project's StringUtils file is different.

Published packages in an ecosystem ought to be well-designed, with good performance, good APIs, good security. Packages that don't meet that bar ought to be kept out. npm is jarring because it let any old shit get published, despite there being long-standing package ecosystems in other languages with much better standards, that they could have copied from (CPAN, PyPi, RubyGems, Maven Central, NuGet Gallery, etc.)

[demosthanos]

The number of distinct entities in your supply chain and whether those developers are on your payroll.

As a business, each additional human or company you add to your supply chain represents additional risk that you're taking on. You can go some ways towards mitigating those risks—one of the most common is to sign a contract with them rather than doing business ad hoc—but the risk doesn't go away entirely. Given that additional risk for each additional downstream supplier, it's generally safer to use code written by someone who's already on your payroll than it is to use code written by someone you've never met and have no way of vetting.