I love how it just blithely takes on another dependency too. This is all too common in JS dev unfortunately… never implement something yourself if you can take on another useless dependency instead.

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 "[email protected]" 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.