Conversely, you don’t have to reinvent the wheel of parsing XML and all the nuances that come with that if you use a tried and tested library.

I see your point and agree with the general sentiment, but this is no leftpad.

Strictly speaking "he@1.2.0" was already present, drug in transitively by something else, that's why the yarn.lock folded the older version into the existing checksum

I came very close to commenting on the PR, but since it was pointed out elsewhere that the fix was to the wrong file, I suspected it was going to be closed wontfix anyway

> never implement something yourself if you can take on another useless dependency instead.

So...your argument is that XML parsing/decoding is useless/too easy and every project should reimplement an XML parser/decoder?

If so, I have 0% trust in your judgement.

They're not doing arbitrary parsing, they just need the ability to un-escape XML characters for a particular case. I'd be shocked if (after all the abstraction) the `he` library didn't just have a single function which does that. I'd prefer just seeing how `he` does it and implementing it myself.

Moreover, they're already using a `fast-xml-parser` for doing XML parsing. Presumably it doesn't have an unescape function, so they're taking on a dependency on another XML parser (and keeping the old one!) just to get the one function.

he is for HTML(/XML) encoding.

It's kinda dumb that fast-xml-parser doesn't full parse the XML and leave content+attribute values in raw forms.

The docs for fast-xml-parser show how to combine it and he.

Had they done that, they wouldn't have this bug that completely breaks the SQS client for me.