Live data from Hacker News

Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

bleepingcomputer.com

131–140 of 1001 posts

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#131
post #82

Earlier quoted context omitted.

> Yes, but AFAIK, those are heavily tested or audited in some manner. That's different from including code written by randos in your app that they can remotely change at any time. It seems like the problem here is more cultural than technical, specifically that the JavaScript community has fully embraced packages that are "written by randos" that are "wrappers around three-line Stack Overflow answers." I use packages…

It's both technical and cultural. Javascript is used on the front end. Front end devs obsess (or at least used to obsess) over download sized. So you'd have crazy stuff like custom builds of Underscore ( https://underscorejs.org/ ) with just the functions you wanted. Think manual sandboxing, if that makes any sense. You could get a package of Underscore with just map, filter and reduceRight, if you wanted to. Now, wh…

The problem with tree shaking has been twofold:

- JavaScript is a very dynamic language with dynamic property access and a few other features that make it hard to guarantee that the linker won't accidentally remove too much

- historically there was no standardized "module" format until ESM (ES modules) came up (with some time in between with few competing non-standardized proposals), so statically analyzing exports/imports was difficult; in frontend you'd long rely on just creating and reading global variables (i.e. side-effects).

Hence it's been "safer"/easier to create small packages.

But it's not only this. Once you put a mega-package in your repo, it's easy to gradually start relying more and more on the things it gives you. Even if it supported perfect tree shaking, you'd call one method here, one method there, and with each build your bundle size would balloon (which is not good if you could write one line of code while lib method's code is 1000 lines because it supports IE4 and 17 parameters).

Whereas when you rely on small packages, you need to make a conscious choice each time to pick another dependency.

You probably don't care about this on servers written in C++ or Java that much; but on frontend it's a big deal; hell, even when building native apps for Android/iOS you have size limits for the stores submission / limits for the number of methods (tech limitation in Android). Big companies invest crazy money to shrink their native bundle sizes (https://blog.pragmaticengineer.com/uber-app-rewrite-yolo/).

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#132
post #12
post #7

Earlier quoted context omitted.

That seems like a bit of a shaky ground to stand on for GH. If someone publishes code for themselves, and at no time asks anyone to take it as a dependency, then at a later date they change that code in a way that breaks other people's use of it, do GH then take over the account?

If they wanted to publish it for themselves, wouldn't they make a private repo? I'm (honestly) trying to understand why GitHub can't just go ahead and remove any account as they see fit. Edit: Am I being downvoted for asking a question?

There are many valid reasons to make code for yourself public, even before discussing the type of license.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#133

Anyone knows what the author meant by the "LIBERTY LIBERTY LIBERTY" message? It's unclear if it's referring to current authoritarian turns in our western world, big corps using his software for free, or something else.

He's a nutjob that blew up his own house while trying to make a bomb or something. There's even an article somewhere. It's not the first time he's being ..weird.

I posted this earlier, but it got flagged. https://news.ycombinator.com/item?id=29859476

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#134

AITA 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…

That's fine, but then the downstream shouldn't complain either when the code breaks, whether intentionally or unintentionally. The contract on paper disclaims all liability after all. There is a social contract and then there is the literal contract. A lot of commenters here seem to be willfully obtuse or simply ignoring the former.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#135

Anyone knows what the author meant by the "LIBERTY LIBERTY LIBERTY" message? It's unclear if it's referring to current authoritarian turns in our western world, big corps using his software for free, or something else.

The author apparently got political, had issues with the law enforcement: https://news.ycombinator.com/item?id=29839786

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#136

Anyone knows what the author meant by the "LIBERTY LIBERTY LIBERTY" message? It's unclear if it's referring to current authoritarian turns in our western world, big corps using his software for free, or something else.

He's a nutjob that blew up his own house while trying to make a bomb or something. There's even an article somewhere. It's not the first time he's being ..weird.

His twitter post. https://twitter.com/marak/status/1320465599319990272

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#137

Imagine they introduced something worse. Could any developer explain to a manager why you needed to import this package? "Why do we need colors there?", "Why can't we make that colored ourself?"

At my last job we (InfoSec) had the devs fill out "ownership" forms for when they want to include something third-party into the product. Other than forcing the team to do due diligence on the third-party it also made them responsible for keeping it secure and them the people "at fault" if something went wrong due to it.

While it was seen as an unnecessary hurdle set up by us I hope it started some meaningful conversations in the teams and maybe even end up with them "reinventing" the wheel for the better.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#138
post #47

This is why you pin all dependencies and upgrade (and test) when it's convenient for _you_, not when the author pushes a new version.

> pin all dependencies You do that. Your coworkers don't. And they'll complain to your boss if you try to make them.

That's when you make a case for why you're pinning them, allowing your coworkers to present counterarguments.

If your boss doesn't take your side, at least you can say "I told you" when things go wrong.

Post reply on HN