search

SukkaW / nolyfill

Speed up your package installation process, reduce your disk usage, and extend the lifespan of your precious SSD.
MIT License
1.11k stars 15 forks source link

Replacing `deep-equal-json` #67

Closed SukkaW closed 5 months ago

SukkaW commented 5 months ago

https://github.com/A11yance/axobject-query/pull/354

shamilovtim commented 5 months ago

I didn't know where else to post this since everything in that thread is locked, but I wanted to point out that the individual who took over that repo and made that PR (https://github.com/A11yance/axobject-query/pull/354) did the exact same thing to react native projects with browserify-sign:

browserify-sign was not his project. He had no history in the repository and no prior contributions. One day he sent a bunch of commits to main (no PRs) where he added numerous bloated dependencies written by him, his own personal github action, his own personal eslint config and released the changes as a patch release into our application. His changes broke the compilation of most apps that use crypto in React Native (specifically react-native-quick-crypto).

After I raised the issue with him, he refused to roll back the changes or release a new patch version. He told me (paraphrasing) to tell the React Native Metro team to learn how to build a correct bundler and blamed them for our problems.

I was able to fix react-native-quick-crypto by removing browserify-sign and several of the other bloated packages but some other ones still resolve transitively against our will because how embedded they are in npm. In our instance this individual caused thousands of people to waste a hundreds of collective hours for a change no one wanted, in a codebase that had no contributions from him. To sum it up, he sent a broken patch release full of his bloated dependencies to thousands (tens of thousands?) of current projects in order to support node v0.

@valadaptive @rich-harris @benmccann

Rich-Harris commented 4 months ago

Maddening.

valadaptive commented 4 months ago

I'm a bit concerned about this leading to more flamewars, pile-ons, slap-fights, and so on, but hopefully these sorts of experiences make their way into the discussion.

I've seen a few maintainers on Twitter talk about firsthand negative experiences they've had with this individual, and I feel like this discussion would be better if those people had more of a voice. My hope when this whole thing kicked off was that the active maintainers in the ecosystem, who had previously been talking about these shenanigans in hushed tones, would feel more empowered to speak up about their own encounters with him. Unfortunately, the discussion seems to have been primarily taken over by people just now learning about this for the first time.

Is there a way we could encourage people with firsthand experience (attempting to contribute to his packages, actively working with him as a maintainer long-term, etc) to speak up without feeling like they're part of a flame war?

shamilovtim commented 4 months ago

Tearing out the libraries he had hijacked turned out to be the only solution for react-native-quick-crypto. It's difficult to address this behavior because, just like in https://github.com/A11yance/axobject-query/pull/354, he closes the thread, blocks the comments and will do what he wants whether it impacts your project or not. I'm not a high-profile developer or influencer with a Twitter presence, and the only thing I could do in my situation was tag the project creator from whom he hijacked the project.

SukkaW commented 4 months ago

Is there a way we could encourage people with firsthand experience (attempting to contribute to his packages, actively working with him as a maintainer long-term, etc) to speak up without feeling like they're part of a flame war?

IMHO, even becoming a maintainer alongside him doesn't stop him from adding those polyfill/packages in the name of compatibility and so-call robustness.

I'm not a high-profile developer or influencer with a Twitter presence, and the only thing I could do in my situation was tag the project creator from whom he hijacked the project.

Considering that not even Rich Harris could change his mind, I doubt there is anyone who can. Not only that, he is already a TC39 member (and previously a Node.js TSC member), so he has way more influence than the community imagine.

shamilovtim commented 4 months ago

I can't even imagine how many projects need such packages removed. It feels like the whole npm registry needs to be forked and its contents thrown away to solve for this and all such packages banned from any new registry based on some heuristics. Manually removing them from npm will probably be impossible.

benmccann commented 4 months ago

It's been going on for a long time, sadly. Here's another example that was just shared: https://github.com/tarruda/has/pull/17#issuecomment-1747898354

Anyway, even if it will take awhile, we can all work together to move forward in positively impacting the ecosystem. There will be an announcement coming soon with details of efforts that are underway from @e18e_dev on Twitter about some great initiatives like https://github.com/es-tooling/eslint-plugin-depend and efforts to proactively address major contributors to bloat in the ecosystem

SukkaW commented 4 months ago

It's been going on for a long time, sadly. Here's another example that was just shared: tarruda/has#17 (comment)

And that's why ljharb is bad. Even the author of core-js is more concerned about spec-compliant and engine compatibility than a current member of TC39. That's also why I recommend core-js in the nolyfill's README.