-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MAINT]: drop aggregate-error dependency #1013
Comments
👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labled with |
I would love to get rid of aggregate error, but one issue is that the built-in type is not generic. If you have a solution that is portable to all platforms let me know. |
I see. I only have the mostly unhelpful observation that it should be possible to either wrap or extend the standard AggregateError type to satisfy the project's typing requirements without taking a runtime dependency on the third party implementation of AggregateError. I see now that the |
Actually there is also a difference between aggregate-error and native AggregateError, when generating the message. aggregate-error basically concats the error messages of all the errors. Native AggregateError expects the message to be the second Parameter of the constructor. So while we could integrate the generic type of AggregateError into our package, the actual breaking change at runtime would be the message part. And probably this could have some sideeffects in probot, when the error needs to be logged. Needs a check in pino on how native AggregateErrors are logged. |
🎉 This issue has been resolved in version 13.3.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Thanks! |
Describe the need
The project's tsconfig targets
es2023
and the stated node support is (at least?) node>16, but it still takes a dependency on aggregate-error, which is made redundant by a standard global for ~4 years now, introduced in versions older than these.This dependency caused me trouble in an arcane monorepo rollup build that is mostly self-inflicted and probably experienced by nobody else, so I won't elaborate on the details. Instead I'll just appeal to the general principle that unneeded dependencies are bad 🌞.
SDK Version
No response
API Version
No response
Relevant log output
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: