If anything, the log4j problem goes a long way to highlight that the "package hell" of node_modules isn't limited to JS apps. log4j is a problem that affects compiled apps written in a mature language. All of the usual complaints about JS apps apply (lots of dependencies, code that's not been audited, developers just adding things without proper consideration, etc), but without the usual "lol javascript isn't a real language!" undertone.
log4j is a problem that affects compiled apps written in a mature language
As a C developer, I disagree with the assertion that Java is a mature language. It's only 26 years old! (And in a practical sense even younger than that, since it has changed a lot since the early versions.)
Fully agree! The point I was trying for is that dependencies have to be managed -- something I've been blathering into the void for a decade, now, without any noticeable impact. Maybe now I'll get those juicy consulting gigs... ;)
It also shows that you have to care not only about the dependencies of your application, but also about the dependencies of applications that you use like Elasticsearch.
>Even when the supply chain attacks are not related to the JS ecosystem, JS/NPM gets mocked - inaccurately even...
js/npm really desirves it, I lost many hours last week because the shitty philosophy of spiting things not in libraries but in mainly functions and add on top of that packages with incorrect package.json, packages that depend on git repositories or shit where package X is bugged on node version Y so you should upgrade node but if I upgrade node then package W is now incompatible. (I inherited this project os is not my fault it uses outdated stuff or shit that is not longer cool).
With this Java log library it seems it does logging and you don't need also a leftpad and isOdd to have it working, some other library that just defines colors, some other library that changes the output from plain text to csv etc.
IMO using 1 lib for logging, 1 for unit tests, 1 for db access, 1 for http, 1 for GUI makes sense , what is stupid is if this 5 libraries combined will depend on 100+ libraries , we need to push against this since the npm philosophy and CV driven development is spreading.
Exactly. People think it is modular and such a great thing to do, but it is not. Maybe it just has to do with flexing. How many libraries do you have? I have 9000! And then in reality it is just one function per library. Or... I have no idea why they think that this is a good thing to do. Can anyone in favor of having "isOdd" function as a library tell me?
You really can’t blame developers for wanting ease of use when it comes to software and tool/library installation. At the same time it is incumbent upon people at all levels of the chain to make sure that security (and effective tools for managing it) are part of the mindset as well as the process.
Actually me who's running a stack of services on Node.JS written in TypeScript had a wonderful weekend. I had my birthday on Sunday and took my girls to Christmas fare. So did my colleagues. The other half of the company were busy resolving the incident ;-)