Honestly, I think the MDN team is in the right here.
The author of the PR provided almost no explanation for the addition and left the template essentially blank. Then the team provided a detailed explanation of a very reasonable policy, to which the PR author responded with what frankly reads like a temper tantrum.
Especially after the xz incident, maintainers should be very very wary of contributors who use manipulative techniques to try to get things merged against policy, and contributors who are trying to help in good faith should be patient and understanding when they hit those barriers.
That's not a very accurate summary. I think you're probably referring to [1] which says
> because polyfills are really hard to get right and we should treat everything as insecure and wrong by default ... I took a brief look at your code and I don't think it's spec-compliant enough to be advertised as a polyfill/ponyfill because it is prone to global pollution.
They then demonstrate that it's not compliant, which the contributor seems to think is not relevant.
Mostly, this contributor comes across as hurt that their PR wasn't immediately merged by virtue of their many years in the field. I might be missing something here though which puts the MDN team in the wrong, but...
> both started the argument with the terrible first reply and escalated the argument with this accusation.
Why was the first reply terrible? They stated the policy and closed the PR. They did so professionally and calmly, and the author immediately threw a fit. Then the MDN person dug into the project more and found specific flaws and pointed them out as further evidence for why the policy (which they already cited and which should have been enough) exists.
> The person from MDN was saying factually incorrect stuff
Do you have specific examples?
> Most of the issue seems to be a systemic problem at Mozilla though.
Frankly, reading through the thread it feels like you started with this as the assumption and had cast the MDN maintainer as the bad guy before the exchange had even started. Mozilla has lots of problems and I'm the first to point them out, but this exchange doesn't demonstrate any of them—it just demonstrates how hard it is in open source to deal with entitled aspiring contributors.
Repeatedly calling it insecure and not to spec when it’s secure and it does the exact same thing unless given unusual input, and is as a ponyfill to ensure the dev is aware of its source when calling it. He also said he has relevant experience when questioned and showed an irrelevant example to support that claim.
Being spec compliant means being compliant with the entire spec, not just a "reasonable subset of the spec", picked by the author of the ponyfill/polyfill. And being secure only in the presence of normal inputs is... pretty meaningless afaict? Anything is secure if the inputs are "nice to the implementation". That isn't a typical bar for "it's secure".
Whether every use case that just wants to roundtrip BigInt through JSON _needs_ a fully spec compliant & generally secure solution is a different question. But at that point it's about picking a solution for a related use case, not about actually standing in for the upcoming browser feature.
> calling it insecure and not to spec when it’s secure and it does the exact same thing unless given unusual input
See, the "unless given unusual input" thing is part of where MDN was in the right and OP is in the wrong.
A polyfill/ponyfill that isn't perfectly spec-compliant can be useful, but it's reasonable for MDN to refuse to endorse it, given that their pages describe the specs. And to try to argue that it still counts as spec compliant when it doesn't handle edge cases is nonsense—the edge cases are why we have specs! If we didn't have to standardize even the edge cases an informal description of the solution would do the trick.
The author of the PR provided almost no explanation for the addition and left the template essentially blank. Then the team provided a detailed explanation of a very reasonable policy, to which the PR author responded with what frankly reads like a temper tantrum.
Especially after the xz incident, maintainers should be very very wary of contributors who use manipulative techniques to try to get things merged against policy, and contributors who are trying to help in good faith should be patient and understanding when they hit those barriers.