Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
D--M2540288dWorks on my machine and my 30 or so production node servers /shrug
sleek1616288dLong live composer ! Long live php !
Root51933288dI, too, hate NPM and what it encourages.
It's continually buggy, and strongly encourages the mindset that "other people's code is always better."
Lightyaer113288dCmon guys it ain't that bad..
Root51933288d@Hubot-0x58 Someone removed their leftpad package and broke much of the internet. 😅
Seriously, who couldn't write a leftpad function? That's like a first year CS problem. And what about depending on little packages that will be abandoned at some point?
You shouldn't write everything yourself, of course: reinventing the steam engine is modestly difficult, but the wheel? bloody trivial. Feel free to "reinvent" it.
But another issue:
There are very real security concerns with using other people's packages. If a project is 10% your code, what is the other 90% doing? To illistrate this with a bit of a strawman: I could easily obfuscate code to steal users' data and mask that behavior from developers, and publish it as a useful-looking npm package. I could write it to only steal data in production, on Thursdays, at random intervals, while the dev tools are closed; detecting it would be nearly impossible. Furthermore, the readable released source doesn't have to match the compiled and minified package, either, so examining its repo wouldn't help. If I convince other devs to include this utility package in their packages, the NPM mentality will eventually have my nefarious package included in large, widely-used projects, and silently stealing the data of millions of users.
Difficult? Less than you'd think.
Root51933287d@CodeBane Everything can be broken and exploited given enough time and effort. That's why the best security people are ex-criminals/hackers/etc. 😋 They know what to look for, and more importantly: how to think.
@Hubot-0x58 Honestly, that's about it. Some common sense too: filesizes that sound right, inspecting rendered pages, etc. Also doing a secondary analysis in production since code behavior changes past the boundary. (I'm thorough/paranoid when it comes to bugs and quality testing, so this is my usual anyway)
The world is a scary place, especially when you blindly trust others and their work.
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job