string.prototype.trimEnd is not used, as this would break when ran on older nodejs runtimes.

Is there a reason why we can't use the built-in trimEnd if it is available and only revert to a custom implementation when it is not?

Is there a reason why we can't use the built-in trimEnd if it is available and only revert to a custom implementation when it is not?

We certainly could. it would be a nice performance improvement for those running node >=10

I think using the built-in trimEnd requires a slight bit more discussion/thought as this strips out more than just & \t (see here). As the library is used widely it is hard to oversee the effects of changing the implementation to use trimEnd.

I do think it's more likely to be an improvement than a regression. I would hoever advocate for making it a different release where consumers can roll back on the trimEnd change without having to roll back to a version that is vulnerable to CVE 2023 26115.

Thanks @OlafConijn !

I'm merging and publishing this fix now.