Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

New day, new npm malware. Sigh..

> New day, new npm malware. Sigh..

This. But the problem seems to go way deeper than npm or whatever package manager is used. I mean, why is anyone consuming a package like colors or tinycolors? Do projects really need to drag in a random dependency to handle these usecases?

So rather than focusing on how Microsoft/npm et al can prevent similar situations in the future, you chose to think about what relevance/importance each individual package has?

There will always be packages that for some people are "but why?" but for others are "thank god I don't have to deal with that myself". Sure, colors and whatnot are tiny packages we probably could do without, but what are you really suggesting here? Someone sits and reviews every published package and rejects it if the package doesn't fit your ideal?

You're partly right.

But the issue isn't just about the “thank god I don't have to deal with that myself” perspective. It's more about asking: do you actually need a dependency, or do you simply want it?

A lot of developers, especially newer ones, tend to blur that distinction. The result is an inflated dependency tree that unnecessarily increases the attack surface for malware.

The "ship fast at all costs" mindset that dominates many startups only makes this worse, since it encourages pulling in packages without much thought to long-term risk.

Why are people using React to write simple ecommerces?

Why are React devs pulling object utils from lodash instead of reimplementing them?

> Why are people using React to write simple ecommerces?

What leads you to believe React is not well suited to simple ecommerce sites?

> So rather than focusing on how Microsoft/npm et al can prevent similar situations in the future, (...)

There's some ignorance in your comment. If you read up on debug & chalk supply chain attack, you'll end up discovering that the attacker gained control of the account through plain old phishing. Through a 2FA reset email, to boot.

What exactly do you expect the likes of Microsoft to do if users hand over their access to third parties? Do you want to fix issues or to pile onto the usual targets?

1. It's a solution meant for highly interactive app-like websites, not static-content driven websites like ecommerces. React in this context is just the wrong tool for the problem that will give you a huge array of performance, bugs and ux problems.

2. Extensive ecommerce experience including Disney, Carnival Cruises, Booking, TUI, and some of the European leaders in real estate and professional home building tools among the others.

> 1. It's a solution meant for highly interactive app-like websites, not static-content driven websites like ecommerces. React in this context is just the wrong tool for the problem that will give you a huge array of performance, bugs and ux problems.

Strongly disagree. React is not about interactivity, but reactivity. If you have to consume an API and update your app based on the responses, React does all the heavy lifting for you without requiring full page reloads.

On top of that, and as a nice perk, React also gives you all the tools you will ever need to optimize perceived performance.

Claiming that a tool designed for reactive programming is not suited for the happy flow of reactive programming is simply fundamentally wrong.

1. React didn't invent SPAs and reactivity.

2. Ecommerces are not highly dynamic pages. They are overwhelmingly static content with an occasional configurator/cart/search. All things that can be embedded with whatever library you like (including React), or even better none at all.

3. Seo and performance is what really matters in ecommerces. The only minor exceptions are shops like Amazon or Airbnb, but that's unrelated to their seo and performance.

4. I've been writing React and ecommerces using React and similar with millions of daily users for a decade :)

It used to be a front end framework everyday