The '50 extra packages' one is wild. The author of those packages has racked up a fuckload of downloads. What a waste of total bandwidth and disk space everywhere. I wonder if it's for clout.
Long time since I thought of that movie.
But, also, he does this "backwards compatibility forever" insanity. I think it's his crusade.
For extra context: I created the tool ~9 months prior to the meltdown as one could vaguely mention an individual trolling over NPM deps and absolutely everyone in the ecosystem with a bit of experience would know who was being referred to, aka, "You Know Who". And, if you dared mention him by name, he'd eventually show up reciting his download counts in endless "appeal to authority"-style arguments, trying to brow-beat people into accepting that he knows more or whatever, ergo, "He Who Must Not Be Named" (at least, if you didn't want him being annoying in your mentions).
There's a number of "-phobia" apps in the ecosystem and given the negative impact he has on dependency trees, it felt fitting to offer a similar, somewhat satirical, app to detect how much of your dependency tree he controlled.
https://x.com/BenjaminMcCann/status/1804295731626545547?lang...
https://github.com/A11yance/axobject-query/pull/354
Specifically Ben McCann along with other Svelte devs got tired of him polluting their dependency trees with massive amount of code and packages and called him out on it. He doubled down and it blew up and everyone started migrating away from his packages.
ljharb also does a lot of work on js standards and is the guy you can thank for globalThis. Guy has terrible taste and insists everyone else should abide by it.
The scheme is based on providing polyfills for deprecated browsers or JavaScript runtimes.
Here is the recipe.
- check what feature is introduced by new releases of a browser/JavaScript runtime,
- put together a polyfill that implements said feature,
- search for projects that use the newly introduced feature,
- post a PR to get the project to consume your polyfill package,
- resort to bad faith arguments to pressure projects to accept your PR arguing nonsense such as "your project must support IE6/nodejs4".
Some projects accept this poisoned pill, and whoever is behind these polyfill packages further uses their popularity in bad faith arguments ("everyone does it and it's a very popular package but you are a bad developer for not using my package")
I had the displeasure of stumbling upon PRs where tis character tries to argue that LTS status does not matter at all I'm determining whether a version of node.js should be maintained, and the fact that said old version of node.js suffers from a known security issue is irrelevant because he asserts it's not a real security issue.
I'm big on Hanlon's Razor too, but that doesn't mean the end result can't be the same.
That person might not be doing it knowingly or on purpose, but regardless of motivations that is definitely what is being done.
EDIT: Oops, he just did the changelog entry. The actual fix was done by someone else: https://github.com/A11yance/aria-query/commit/f5b8f4c9001ba7...
I am.
If you check the definition of polyfill, you'll eventually arrive at something like the following:
> A polyfill is a piece of code (usually JavaScript on the Web) used to provide modern functionality on older browsers that do not natively support it.
https://developer.mozilla.org/en-US/docs/Glossary/Polyfill
I think we would agree that foreach fits the definition, happy path, and whole purpose of a polyfill.
if you read up on forEach, you will notice that Array.prototype.forEach requires objects to be callable.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I think you got that all wrong and strongly misinterpret "modern functionality" as some generic library here...
Runtimes are developed against a certain spec, in this case ECMAScript, and "modern functionality" is meant as addition to iterations of such a spec. As it happens, iterations of specifications and runtimes are seldomly provided by the same entity, so both are moving forward with newly supported features, or more "modern functionality", individually.
This behavior provokes some difficult challenges for developers. For once, they would like to work against the latest spec with its newest features, but, due to the natural dynamic of various entities doing things in different ways, these developers would also need to support older/other runtimes where such a feature is not (yet) implemented natively. Now, to bridge these supported-feature-gaps developers came up with an interesting concept: Instead of waiting and relying on the runtime to support such a new feature, it might be possible to provide an implementation as workaround, hence the "polyfill".
So, if something A isn't currently in the spec, nor B even proposed or in discussion to be in the spec, nor C provided by any current runtime (and relied upon by developers), then I'd conclude that such a functionality is not considered to be a polyfill, as it isn't to be seen as workaround for the supported-feature-gaps due to the difference in runtimes.
I didn't. I am telling you exactly why polyfills exist, and why people use them.
More importantly, I am explaining to you why this scheme is successful.
You don't need to write any wall of text that adds nothing. Read the facts I laid out, and use that to either understand how things work, or don't. It's your choice.
More generously, I am explaining to you why your definition of a "polyfill" "is [NOT] successful" and isn't how it's commonly understood.
But you do you, it's fine.
[0]: https://www.npmjs.com/package/for-each
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://github.com/nodejs/node/issues/55918
so.. I don't know. if he wanted to bad he would already
The problem with this view is that the JS ecosystem is already doing that all on its own without that particular contributor. (as has the rust ecosystem, which slavishly copied JS' bad practices).
Eliminate the one guy and JS is still pervasively vulnerable to these attacks. The polyfills are the least of it, because at least they should be completely stable and could just be copied into projects. Other dependencies not so much.
Especially if you could control at install time just how far back to go, that might be interesting.
Also an immediately ridiculous graph problem for all but trivial cases.