Stories
Slash Boxes
Comments

SoylentNews is people

Submission Preview

‘No Way to Prevent This’, Says Only Development Community Where This Regularly Happens

Rejected submission by upstart at 2019-07-30 14:16:39
/dev/random

████ This a robot sub whomst needing edited. Please report broken subs to chromeass, ████

Submitted via IRC for AndyTheAbsurd

‘No way to prevent this’, Says Only Development Community Where This Regularly Happens [medium.com]

‘No way to prevent this’, Says Only Development Community Where This Regularly Happens Sebastian K [medium.com]FollowJul 30 [medium.com] · 3 min read

PURESCRIPT, NPM — In the hours following another package disaster on npm in which a lone developer killed more than dozens of CI builds and caused serious warnings in thousands of others, developers of the only community where this kind of disaster routinely occurs reportedly concluded Monday that there was no way to prevent the disaster from taking place. “This was a terrible tragedy, but sometimes these things just happen and there’s nothing anyone can do to stop them,” said fullstack developer Bob Dynald on Reddit, echoing sentiments expressed by tens of millions of individuals who take part in the programming community where over half the world’s most infuriating package management disasters have occurred in the past 9 years and whose members are 200 times more likely to experience unexpected package updates than those of other established communities. “It’s a shame, but what can we do? There really wasn’t anything that was going to keep these individuals from snapping and ruining a lot of people’s day if that’s what they really wanted.” At press time, residents of the only big established development community in the world where roughly two package management disasters have occurred every month for the past four years were referring to themselves and their situation as “helpless.”

PURESCRIPT, NPM — In the hours following another package disaster on npm in which a lone developer killed more than dozens of CI builds and caused serious warnings in thousands of others, developers of the only community where this kind of disaster routinely occurs reportedly concluded Monday that there was no way to prevent the disaster from taking place. “This was a terrible tragedy, but sometimes these things just happen and there’s nothing anyone can do to stop them,” said fullstack developer Bob Dynald on Reddit, echoing sentiments expressed by tens of millions of individuals who take part in the programming community where over half the world’s most infuriating package management disasters have occurred in the past 9 years and whose members are 200 times more likely to experience unexpected package updates than those of other established communities. “It’s a shame, but what can we do? There really wasn’t anything that was going to keep these individuals from snapping and ruining a lot of people’s day if that’s what they really wanted.” At press time, residents of the only big established development community in the world where roughly two package management disasters have occurred every month for the past four years were referring to themselves and their situation as “helpless.”

This post was inspired by the “No Way To Prevent This,’ Says Only Nation Where This Regularly Happens [theonion.com]” articles released by The Onion. It may contain sarcasm.

Edit: Besides some personal threats I have received in response to this parody/sarcastic joke, I have been asked to make suggestions how to fix the problem, here’s an incomplete list of what I personally think is wrong with npm:

  • npm (client and registry) is a flawed system, and would need to be completely replaced, the new system should have the following features to mitigate the possibility of such incidents:
  • No unscoped packages
  • Scopes are 1-to-1 bound to a single user/organization
  • Publishing packages requires 2FA, the package must be signed via GPG
  • Unpublishing packages is not allowed for anyone but the registry maintainers (Yanking, as Rust’s cargo does it, is another possible solution)
  • 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

In regards to the whole ecosystem: TC39 should take a look into adding a better standard library to JS itself, which would reduce the amount of one-liner packages. There is an active proposal [github.com], which is however met with contempt by many JS community members.

If you are interested in the events which lead to this post, here’s a list of recent and past npm incidents, be it the fault of npm’s security measures, bad architecture, fun anecdotes, or the low hurdles required to jump over to publish a package on the registry:

hashtag satire


Original Submission