[FEATURE] Consider Alternative Implementations for cause in ErrorOptions to Maintain Lower Compilation Target Compatibility

[andreas-karlsson]

Requirements

A while back, PR #765 was merged, introducing support for the cause property in ErrorOptions. This was implemented by changing the compilation target from es2015 to es2022. However, this change may cause compilation errors for SDK users who are compiling to a lower target and have skipLibChecks:false.

While the cause functionality is a valuable addition, I'm concerned about the potential impact on runtime support. Is the added functionality worth the potential decrease in compatibility?

I'm wondering if there might be alternative ways to implement this feature without changing the compilation target. For instance, could we manually set the cause property where needed? This approach might be compatible with both older and newer runtimes, and could potentially avoid the issue altogether.

I'm interested in hearing your thoughts, and open to contributing a PR.

[beeme1mr]

We made this change because Node 16 has solid support for es2022 and it's the oldest LTS version still supported. However, you mentioned that it may cause issues when targeting es2015 when skipLibChecks: false is set. I believe es2015 is still the default when you run ts init, so we may want to try and target that, if possible. Perhaps a polyfill would be enough.

What do you think @lukas-reining @toddbaert?

[lukas-reining]

This makes sense @andreas-karlsson.
I think we could go for a polyfill here @beeme1mr, I am just not sure if this works for TS types.

[beeme1mr]

I decided not to use a polyfill because it wasn't necessary and may lead to unexpected consequences.

[andreas-karlsson]

Thanks for speedy resolution! ❤️