You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
## This PR
- replace the es2022 error cause with a custom implementation
- lower compilation target from es2022 to es2015
### Related Issues
Fixes#956
### Notes
The tests pass, but I still want to manually build and test the outputs
in a real application to ensure everything works as expected.
Signed-off-by: Michael Beemer <[email protected]>
Requirements
A while back, PR #765 was merged, introducing support for the
cause
property inErrorOptions
. This was implemented by changing the compilation target fromes2015
toes2022
. However, this change may cause compilation errors for SDK users who are compiling to a lower target and haveskipLibChecks: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.
The text was updated successfully, but these errors were encountered: