GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724
On what basis?!
Bad faith?
Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
211–220 of 1001 posts
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#212Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#213AITA for thinking that if you develop open-source software and your license permits anyone to use it for free, then complaining about no compensation is not a valid complaint? I totally understand that billionaire corporations use software like this for free. But the software maintainer has explicitly allowed _anyone_ to use it for free. If you don't want them to use it for free, license it as such. What am I not see…
Yea it sounds like baiting with something free to get users, then switching to solicitor mode.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#214Earlier quoted context omitted.
no. is it really that complex of a concept that intent of a change matters too, and introducing an endless loop to cause trouble to users is different from a legitimate API change that does a useful thing?
Who are you to decide what is useful/legitimate or not? As a user of $ExampleLibrary, I surely know best what's useful rather than the maintainer.
I think it's safe to say that people who download a data-generation library intended for testing are not looking for infinite loops.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#215At some point people need to stop pulling in random unsigned libraries from the internet and deploying them without any review or testing. This chaos seems like it would be entirely preventable with just a small sprinkling of best practices.
Signing would not have helped at all here - the author decided to nuke their project (and likely their last reputation), they could have signed that commit/package.
Requiring multiple signatures from several trusted sources would have.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#216GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724
This is scary, and I don’t know why people here aren’t losing their minds. I think someone should make a big deal about this. What would be the first step? On the other hand, my GitHub was once suspended (and all repos shuttered) for posting gists that looked like spam to some algorithm. It was extremely unsettling, and they need to do a better job communicating. But they may have suspended the account because they t…
GitHub is a private enterprise, never forget that… It's not scary, GitHub is a community owned by a corporation, and they have every right to kick this guy to the curb as he is a bad actor. This is the same reason I'm cool with them kicking MAGAs spreading lies to the curb. It's one thing to remove/deprecate an NPM package, it's another thing to deliberately break 10s of thousands of software installations because you want to act like a baby. He no doubt did thousands if not hundreds of thousands of dollars in damage and will continue to do so as developers find their stuff broken all over the internet.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#217Earlier quoted context omitted.
That's another JS ecosystem widespread malpractice. Autobumping versions, or version ranges as they're called in Maven land. Dependencies should only use fixed versions and all updates should be manual. You should only use auto-upgradable versions during development, and the package manager should warn you that you're using them (or your dependencies are).
If package A depends on package C at version 1.0 but package B depends on C at version 1.1, what version of C will be pulled in? Dependency management is not as simple as only upgrading one direct dependency at a time after careful review. The NPM ecosystem is particularly difficult to work with as it has deep and broad transitive dependency trees, many small packages, and a very high rate of change. You either freez…
There are package exclusions, package forcing and of course, full dependency tree checks where you review what everything pulls in.
The JS ecosystem will probably have to change but because it's so decentralized, that change will be orders of magnitude harder than, for example, PHPs transition from 3 (4, 5) to 7.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#218Earlier quoted context omitted.
When you publish free software you give it away as a gift. That's the point. Expecting compensation for a gift is the error.
Free as in freedom is not the same as free as in beer. This model where someone develops something for free and then those that benefit the most don't contribute back isn't sustainable. I don't know if the packages owner was conscious about it but this was a political act and hopefully the impact will be positive. From where we are we have two options: (1) companies find a way to make open source financially rewardin…
> Free as in freedom is not the same as free as in beer.
It's a choice to distribute software for "free" as in "free beer".
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#219Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#220At some point people need to stop pulling in random unsigned libraries from the internet and deploying them without any review or testing. This chaos seems like it would be entirely preventable with just a small sprinkling of best practices.
Time and time again I'll keep saying this: This problem is only solved with package repositories that require review by a maintainer to publish. Linux distributions solved this ages ago.
Change that to multiple maintainers. Best practices should mean that any single point of failure is mitigated. I'm shocked to say it, but the blockchain might actually be a useful model for trust here.