5 ms·
‘No Way to Prevent This’ Says Development Community Where This Regularly Happens
- chasingthewind 7y agoI wasn't sure what the post was about from the title but this is a satirical article about the recent NPM issue with purescript-installer.
- Nimelrian 7y agoAuthor here! Yeah, it was just a parody of the articles The Onion regularly releases regarding another topic and to be honest I didn't quite expect my post to take off the way it did. I'm also sorry I posted it on Medium, which I personally dislike, but since Medium is frequented by many JS devs it seemed the ideal place to put that joke.
- visviva 7y agoThe title makes no sense as a joke (unlike the original).
- Cpoll 7y agoIndeed, the 'Only' in 'Only Development Community' is missing in the HN title.
- SolaceQuantum 7y agoIsn't this a riff of the onion article regarding mass shootings, but with the npm installer? [0] [0] https://www.theonion.com/no-way-to-prevent-this-says-only-nation-where-this-r-1823016659 https://www.theonion.com/no-way-to-prevent-this-says-only-na...
- KaiserPro 7y agoyes, as mentioned in the article.
- Nimelrian 7y agoYou are indeed correct in that assessment. I actually put it into a small footnote in case people reading the post miss the "joke".
- kortilla 7y agoYou screwed it up though. It needs to be “...Says Only Development...” Otherwise it sounds like you could easily be describing something that can’t be prevented.
- Nimelrian 7y agoI didn't create the post here, only the original one on Medium. I can't correct the title over here.
- chrisan 7y agosorry the title was too long, I had to cut a word! edit: I also had no idea about the shooting yesterday I tend to stay away from the news as it is far too politicized these days and normally just leaves me angry/unhappy
- lonelappde 7y agoYes it's a poor taste knockoff that botches the delivery by missing the critical word "only".
- na85 7y agoPoor taste? I thought it was on-point and hilarious.
- citizenkeen 7y agoNo it doesn't. The person who shared it edited the title, but the author didn't miss the critical word.
- jfengel 7y agoIndeed. The article isn't about developers in general, but about NPM in particular. Other repositories are more stable.
- ubermonkey 7y agoYeah, it is, and honestly I think it's a little inappropriate.
- beamatronic 7y agoGiven the context of the Gilroy shooting yesterday, I’d agree.
- Nimelrian 7y agoI'm living outside of the US and this is the first time I heard of this. I did not have any intentions to link my release to a recent shooting.
- mieseratte 7y agoAren't shootings a daily occurrence in the US? Are we never allowed to allude because of recency?
- apacheCamel 7y agoHonest question: When is it appropriate to talk about this stuff? I see this often: "We are speaking about <event> too soon after it happened, we need to let the families <grieve|move on|have space>." It seems like one <event> happens, we can't talk about it, then a new one happens and the cycle goes on, never stopping to sit down and discuss how we keep ending up here.
- drewbug01 7y agoIt's appropriate _now_ to discuss the shooting; but I'm not really sure it's ever going to be appropriate to turn the Onion's blistering satire into a punchline here. What the Onion did is a valid, necessary, mildly amusing, but incredibly pointed and powerful criticism of the gun problem in America. What this article is doing is making that criticism into a punchline in and of itself. That is what is disrespectful.
- SAI_Peregrinus 7y ago
- beamatronic 7y agoYes, along the same lines it could also say “npm installer considered harmful”
- aogl 7y agoWhat a click bait title!
- KaiserPro 7y agoThis made me chuckle. As for the "how to fix" I suspect the biggest step forward would be creating a decent standard library.
- Nimelrian 7y agoThat would definitely fix the "my small React CRUD SPA relies on 10k package maintainers" issue, but would still leave other issues open. There's actually an active proposal for a standard library, but it is met with a lot of contempt from the JS community [0] [0] https://github.com/tc39/proposal-javascript-standard-library/issues/19 https://github.com/tc39/proposal-javascript-standard-library...
- pjc50 7y ago> "A lot of effort has been put by individuals to promote new ideas. Many of those innovators get nothing out of their effort but the fame of their library. The TC39 would gain the power to render an existing effort mute and thereby ruining a life's work. What do you intend to do to prevent private agendas resulting into half-baked and/or derivative solutions that might do more harm to the ecosystem than good?" I don't want to swear on HN, so I'll just say .. wow. So there are elements of the community who want to keep the deficiencies there so they can get micro-fame for filling them? People want to feel important by maintaining left-pad? (also I think they meant moot rather than mute, but hey; also, this is software, we don't really respect idea precedence and any work may be rendered moot by the work of others at almost any time as technology shifts.)
- horsawlarway 7y agoThere are better things to be wow'd over than a random encounter with an online idiot. It's the most used language in the world, there are plenty of idiots to be found.
- horsawlarway 7y agoExcept you're not really solving the right problem. The problem is not that the standard library is bad (It could be shite, it could be gold, it doesn't really matter). The problem is that regardless of what's in your "standard" library, you will have a VERY long tail of users interacting with your code in a user agent that just doesn't support it. Period. So I think you can rephrase this whole conversation as not "make a better standard library!" but instead as "how do we bootstrap a better standard library into user agents that haven't been updated in 10 years?" In which case suddenly NPM/Babel/Webpack start to make a lot of sense.
- jrochkind1 7y ago> Fuzzy dependency versions (^2.0.0 and alike) should not be allowed in final versions. Multiple times I have witnessed npm modifying the package lock file of a project when running npm install after a fresh clone, downloading newer versions of transitive dependencies than those specified in the lock file That sounds like a bug or mis-design in npm, if it's not respecting versions in the lockfile, when no top-level dependency requirements have changed. Isn't the lockfile supposed to... lock? If you don't allow dependencies to express ranged requirements on their dependencies (your transitive/indirect dependencies), it means that whenever an indirect/transitive dependency releases a security fix, you need to wait on anything in the dependency tree that refers to the fixed thing to release an update, and hope it releases an update without breaking changes for your app. That doesn't sound like where you want to be.
- bryanlarsen 7y agoYou should be using `npm ci` or `yarn --pure-lockfile` instead of npm install. Of course that can't be the default because of "legacy". That's the burden of a Javascript dev, carrying around lots of knowledge about what you shouldn't use.
- sneak 7y agoOr they could just, you know, fix it. I think that was the point of the author of TFA.
- mieseratte 7y ago> Of course that can't be the default because of "legacy". Then why did they change the default behavior to use fuzzy matching? Because someone decided it was the best decision. It isn't about breaking changes, it's about someone's arbitrary decisions and those decisions are arguable.
- Ajedi32 7y agoYeah, that statement was rather surprising. The lockfile does lock versions. The only time NPM will modify the lockfile on install is if you install a new dependency or modify the package file to require a package version range that contradicts what's currently in the lockfile. So while it is possible that npm would modify the lockfile after a fresh clone, the only way that could happen would be if the package.json file was already out of sync with the lockfile on the branch you checked out.
- s_Hogg 7y agoIs there actually a decent alternative to JS for front end stuff? Another part of the solution to this language turning into the blob monster from the end of Akira surely has to be making those with an interest in the language's success less complacent. I mean, why argue for _not_ having a standard library?
- repolfx 7y agoSure. Write a desktop app with something like JavaFX or Qt.
- s_Hogg 7y agoHmm fair point
- ilikehurdles 7y agoClojurescript, Elm, and Dart come to mind.
- akatechis 7y agoThere's also PureScript snicker
- K0nserv 7y agoI wrote two comments[0][1] on Reddit about this, but I think there's a bit of JS-bashing happening here since a lot of the issues described here are relevant for many other package managers other than NPM. There are notable problems with how modern software is built with deep dependency graphs and the potential supply chain attacks that are possible because of this, but none of that is exclusive to NPM. NPM has a preference for small single purpose packages and JS is massively popular which might make this problem worse, but it's a problem for a lot more communities and languages than JS/NPM. 0: https://www.reddit.com/r/programming/comments/cjnoqi/no_way_to_prevent_this_says_only_development/evfa7qx/ https://www.reddit.com/r/programming/comments/cjnoqi/no_way_... 1: https://www.reddit.com/r/programming/comments/cjnoqi/no_way_to_prevent_this_says_only_development/evfbtdl/ https://www.reddit.com/r/programming/comments/cjnoqi/no_way_...
- hedora 7y agoThe problems mentioned are relevant to other package managers and languages, but they’re obvious problems that other package managers solved 20+ years ago. Even the ones that haven’t solved the underlying problems have done substantially better jobs mitigating them than NPM. (pip and docker hub are the only counterexamples that come to mind).
- K0nserv 7y ago> The problems mentioned are relevant to other package managers and languages, but they’re obvious problems that other package managers solved 20+ years ago. Which package mangers and how? The ones I can think of[0] and are familiar with suffer from the same or very similar problems[1]. 0: Bundler, Cargo, CocoaPods, Composer, Pip(to a lesser extent) 1: Name squatting, typo squatting, malicious versions via compromised accounts/publishing credentials, compromises to the delivery infrastructure(AFAIK NPM protects against this with the integrity field in package-json.lock)
- danShumway 7y agoMore to the point, if a package maintainer turns malicious, as it appears was the case here, none of the changes this article is suggesting will help at all. 2FA means nothing if you can't trust the person publishing the package.
- danShumway 7y agoI'm not finding this article substantive, it appears to be trying to pick a fight for its own sake rather than adding anything new or interesting to the broader discussion around package security. I haven't seen data that suggests that NPM malware is more common than most other package managers when you adjust for relative size and rate of new packages. It's not clear to me how any of the suggested changes that the author proposes would have stopped the last attack, since it likely involved a package author deliberately sabotaging their own package. The author ignores any of the technical considerations as to why standard libraries are kept small in Javascript. It's an oversimplification of an extremely complicated topic. Javascript has concerns that languages like Python, Ruby, and PHP don't -- namely backwards compatibility and the inability to correct bad decisions once they've been made. The article is filled with claims that just don't make sense or are outright wrong (unpublishing packages is already not allowed on NPM). I want to assume the author does actually have experience on the web, and they're not just mad that Javascript/Node exists -- so from a charitable interpretation, this article could have done more to dig into why the recent NPM scare is fundamentally different from similar situations that have popped up recently in, say, Ruby Gems[0]. [0]: https://gbhackers.com/rubygems-strong_password/ https://gbhackers.com/rubygems-strong_password/
- drewbug01 7y agoHot take: The Onion's version of this article is a blistering, sobering satire. The verbatim re-posting for different mass shootings [1] makes even more powerful. This article, however, is inappropriate and offensive because it takes that quite necessary critique and turns it into a joke. The Onion wasn't joking with their article. Satire isn't just about humor (though it sometimes leverages it). This author entirely missed the point of what the Onion did and should really re-think if this is something they want to be associated with. It's entirely appropriate to talk about gun control and gun reform, all the time - even (and especially) immediately after a mass shooting. It's never appropriate to turn the mass shooting tragedy into a punchline for to get more clicks on your article. 1: https://www.theonion.com/search?blogId=1636079510&q=%E2%80%98No%20Way%20To%20Prevent%20This%2C%E2%80%99%20Says%20Only%20Nation%20Where%20This%20Regularly%20Happens×tamp=1564502356010 https://www.theonion.com/search?blogId=1636079510&q=%E2%80%9...