5 ms·
I knew npm was a train wreck when I first used it years ago and it pulled in literally hundreds of dependencies for a simple app. I avoid anything that uses it
by jbd0 1y ago
I knew npm was a train wreck when I first used it years ago and it pulled in literally hundreds of dependencies for a simple app. I avoid anything that uses it like the plague.
- zachrip 1y agoI can tell a lot about a dev by the fact that they single out npm/js for this supply chain issue.
- hsbauauvhabzb 1y agoThat they’ve coded in more than one language?
- deleted 1y ago[deleted]
- brobdingnagians 1y agoLots of languages ecosystems have this problem, but it is especially prominent in JS and lies on a spectrum. For comparison, in the C/C++ ecosystem it is prominent to have libraries advertising that they have zero dependencies and header only or one common major library like Boost.
- RUnconcerned 1y agoWhat other language ecosystems have had this happen systematically? This isn't even the first time this month!
- blueflow 1y agoPython/PyPi.
- johnisgood 1y agoRust.
- LPisGood 1y agoGo has this issue
- SkyPuncher 1y agoNPM is the most popular, so it happens the most frequently. All of the other ecosystems are just as susceptible. Unix had a big scare last year because of XZ Utils. https://en.wikipedia.org/wiki/XZ_Utils_backdoor https://en.wikipedia.org/wiki/XZ_Utils_backdoor
- Sankozi 1y agoNo they are not as susceptible - auto updating dependencies, post install scripts and culture of thousands of crappy micro packages (like left-pad) is mainly a NPM issue.
- zachrip 1y agoPackages are not auto updated if you have a package-lock. Agreed that post-install, left-pad, etc have been overall problematic tho.
- mdavidn 1y agoRubyGems is susceptible too.
- lithos 1y agoJust more engineering leaning than you. Actual engineers have to analyze their supply chains, and so makes sense they would be baffled by NPM dependency trees that utterly normal projects grow into in the JavaScript ecosystem.
- zachrip 1y agoDo you think companies using node don't analyze supply chains? That's nonsense. Have you cargo installed a rust app recently? This isn't just a js issue. This needs to be solved across the industry and npm frankly has done a horrible job at it. We let people with billions of downloads a month with recently changed password/2fa publish packages? Why don't we pool assets as a collective to scan newly published packages before they're allowed to be installed? These types of things really should exist across all package registries (and my really hot take is that we probably don't need a registry for every language, either!).
- LaGrange 1y ago> Do you think companies using node don't analyze supply chains? I _know_ many don’t. In fact suggesting doing it is a good way to be looked at like a crazy person and be told something like “this is a yes place not a no place.”
- pclmulqdq 1y agoIt is solved across the industry for those who care. If you use cargo, npm, or a python package manager, you may have a service that handles static versioning of dependencies for security purposes. If you don't, you aren't generally working in a language that encourages so much package use.
- keyle 1y ago2FA would certainly help, however you'd still have malware like these silently updating code and waiting for the next release. We'd have to rely on the developer to notice, and check every line of code they ship, which might be the norm but certainly not 100% of cases.
- 1y ago
- Aeolun 1y agoI think it’s just that a lot of old men don’t like how popular it has become with script kiddies.
- cedws 1y agoThe JavaScript ecosystem has a major case of import-everything disease that acts as a catalyst for supply chain attacks. left-pad as one example of many.
- oVerde 1y agoSo basically you live JavaScript free?
- Arch-TK 1y agoI mean, it's hard to avoid indirectly using things that use npm, e.g. websites or whatever. But it's pretty easy to never have to run npm on your local machine, yes.
- Xelbair 1y agoas much as i can yes. I try to avoid JS, as it is a horrible language, by design. That does include TS, but it at least is useable, but barely - because it still tied to JS itself.
- diggan 1y agoOff-topic, but I love how different programmers think about things, and how nothing really is "correct" or "incorrect". Started thinking about it because for me it's the opposite, JS is an OK and at least usable language, as long as you avoid TS and all that comes with it. Still, even I who'd call myself a JavaScript developer also try to avoid desktop applications made with just JS :)
- Xelbair 1y agoJS's issue is that it allows you to run an objectively wrong code without throwing explicit error to the user, it just fails silently or does something magical. Seems innocent, until you realize what we use JS for, other than silly websites or ERP dashboards. It is full of gotchas that serves 0 purpose nowadays. Also remember that it is basically a Lisp wearing Java skin on top, originally designed in less than 2 weeks. Typescript is one of few things that puts safety barrier and sane static error checking that makes JS bearable to use - but it still has to fall down to how JS works in the end so it suffers from same core architectural problems.
- diggan 1y ago
- epolanski 1y ago"I knew you weren't a great engineer the moment you started pulling dependencies for a simple app" You realize my point right? People are taught to not reinvent the wheel at work (mostly for good reasons) so that's what they do, me and you included. You ain't gonna be bothered to write html and manual manipulation, the people that will give you libraries to do so won't be bothered reimplementing parsers and file watchers, file watcher writers won't be bothered reimplementing file system utils, file system utils developers won't be bothered reimplementing structured cloning or event loops, etc, etc. I myself just the other day had the task of converting HTML to markdown, because I don't remember whether it was Jira or Github APIs that returns comments as HTML and despite it being mostly few hours of work that would get us 90% there everybody was in favor of pulling a dependency to do so (with its own dependencies) and thus further exposing our application to those risks.
- komali2 1y agoPause, you could write an HTML to markdown library in half a day? Like, 4 hours? Or 12? Either way damn
- epolanski 1y agoOne that gets me 90% there would take me few hours, one that gets me 99% there few months, which is why eventually people would rather pull a dependency.
- williamcotton 1y agoOr about 15 minutes with an LLM? https://github.com/williamcotton/markdown-to-html-llm https://github.com/williamcotton/markdown-to-html-llm ;)
- neilv 1y agoIn less time than that, you could `git clone` the desired open source package, and text search & replace the author's name with your own.