What's nuts is that any of these projects (whether they be single components, larger utilities, or full-blown apps) require a build step that involves anything more complicated[1] than a single machine-readable document in the web browser's native file format and that sits alongside (or in place of[2]) the project README. With so many programmers writing code for the express purpose of making digital documents with behavior dynamic enough to trick you into thinking that the page you have open is really an app, no one in the community with any clout ever stops and says, "Gee, since we're at it, maybe we ought to take this tech that enables us to securely run code on demand and focus it on the goal of allowing other programmers to configure all these modules that we're sharing with one another, or to handle the finishing step of a collection of modules that make up a given app."
Then again, that would presume that any of the stuff that this industry engages in is actually meant to solve any problem, rather than creating a neverending supply of them in order to justify the paychecks being written and the egos they're feeding. If stuff's not laughably overengineered to the point of constantly breaking for no good reason[3], does it even count as "real"[4] programming?
1. https://www.colbyrussell.com/2019/03/06/how-to-displace-java...
2. https://news.ycombinator.com/item?id=28407936
This malware was lurking in an auto-executing script that runs upon merely trying to fetch the module. Under the regime that I outlined, malicious actors would be forced to try doing their dirty work within the module's business logic itself, which is far easier to mitigate—for example, with a policy where no code gets merged into the application without undergoing review, whether it is written by a third-party or someone on your team. In spite of all the craziness that the 2010s led to with the rise of specialized package registries trying to recreate CPAN (often erroneously called "language package managers") and giving the illusion that there is such a thing as a free lunch, we're going to have to eventually deal with reality and accept that this is the only reasonable way to approach software development for the stuff that we need to rely on (and that no amount of trying to sweep the problem under the rug with references to Trusting Trust will make the counterargument a sound one).