This joke is made a lot but I think most good developers take care in considering the npm dependencies they install. You can get a ton of dependencies pretty easily by just installing very popular ones like react, tailwind, nextjs, etc. If there's ever a dependency that I'm not familiar with then I make sure to take at least a cursory look over the repo to make sure it has a decent number of stars/community, is well maintained, has multiple contributors, etc.
That is great, but the reality is that your OS, the productivity software you use daily, and the dependencies downstream of the ones you review, are not actually being checked by you for code quality.
Part of using software is just going off how well it works.
When one Linux flavor starts to have issues, most people don't do a dissection on why, they just switch distros. Or web browsers (I've lost count of the back-and-forth between FF and Chrome performance over the years, nevermind all their precursors). Or office suites.
Pretending that the code is what really matters, and not what the code does, is elevating the paint quality over the painting.
I didn't mention the code once in my reply. Code is only one aspect of reviewing a dependency. Much more important is the community and support around the tool/dependency.
When dealing with LLM output, you're getting a 1 of 1. There's no way to measure the community, number of contributors, or how maintainable it is.
Beyond ongoing support, community/number of contributors doesn't indicate anything, though?
And maintainability is a function of code, as it relates to humans, so it is a measure of the code itself.
One of the things I've actually seen companies considering (due to supply chain compromise attacks), is not just having an in-house package repo that trails public versions, but instead fully in-housing critical dependencies and essentially making them private forks that they (probably use LLMs to) maintain.
Basically cutting out the Chainguard-like companies that made private deps their business model.
You can argue that correlation doesn't imply causation, but typically more contributors means more people who have played a part in the code and so more eyes on the project to catch issues as well as a higher bus factor and less key person risk.
And larger community means there's more rewards for a successful attack and therefore fewer latent security issues (ie, obvious ones are more likely to be caught).
I think companies considering building in-house packages are just trading one risk for another. Especially with LLMs, it's going to be a lot easier to find vulnerabilities in your internal dependency than it would be in a battle hardened dependency used by 100s of others.
Honestly, I see good points in both of your comment sets.
But there really is a floor on how deeply a person can understand their own software. There has to be a "good enough" somewhere. As a C# dev, I can understand my entire codebase pretty deeply. And I've read enough of the .NET Core framework to understand some of the nuances of how a lot of the methods we rely on every day are implemented. But I've never once looked at the CIL that Roslyn has produced, and certainly not inspected the machine code that the runtime has compiled. I can't read or write Assembly. I don't really know anything about the x86 or ARM instruction sets. My understanding of the CPU is barely better than "it's transistors," and even lower than that, I have a vague awareness that neutrinos from space can flip bits and there are error correcting mechanisms for that, but I have no idea how they work. And yet, I'm able to write fast and reliable software.
There are super knowledgeable devs out there who pretty much DO understand the whole thing, but it's impossible to memorize every line of every version of framework that you're using or the unique alterations and upgrades to every piece of silicon that your program will run on, and as you guys pointed out, proprietary operating systems are basically completely opaque to our understanding.
So the question is really "where is the practical floor that you stand on?" And for me, personally, there is room for at least some areas of code at the application level that I'm OK with never having read myself.
I think the person above is stating that this is distinguishing characteristic of "good" developers. By extension, the ones you are referring to are not good.
We need to build systems where trust in the code is not needed.
I don't trust the JavaScript code I run in my browser, I don't need to.
A language with a strong enough type system and effects system could say, "this function updates the users preferences, and may not access the network, and may not access data from other users", and the compiler can ensure these constraints AT COMPILE TIME! Provably correct code.
That's a strawman argument. I'm just saying that we need to find ways to wrangle the mountains of code coming out of LLMs into something we can trust, as best we can.
Where do you find these guys? I haven't worked on a project with more than 20 dependencies, and usually those dependencies have 0 subdependencies so they're quite easy to audit.
Not sure how you operate, but I've never worked on any project in my 10+ years as a professionally employed JS dev where we've shipped Jest in our release.
I don't audit all the code I run (I don't think anyone does), but I do audit all the code I _release_. What's actually important to you?
That's a fair point, and with newer package managers, at least the dependencies no longer automatically execute build scripts on install.
There were a few common sources of large runtime dependencies in the past. Like the browserify Node polyfills, babel-polyfill and runtime with core-js, React -> fbjs, Material UI -> JSS and plugins, styled-components.
It's also not trivial to tell whether a dependency you listed under devDependencies is actually imported and consequently bundled into your production build.
Since today we no longer need polyfills and the modern stack with Vite etc. doesn't have a sprawling dependency tree, I think things are now looking much better.
You don't have to ship a dependency for it to be a vulnerability; the shai hulud worm was attacking dev machines and cicd environments to steal credentials. The deps you run are absolutely just as critical.
proceeds to install 200 random npm dependencies