Skip to content
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

Update dependency @cordis/common to ^0.3.0 #2

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

renovate[bot]
Copy link

@renovate renovate bot commented Oct 1, 2023

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@cordis/common ^0.2.3 -> ^0.3.0 age adoption passing confidence

Release Notes

cordis-lib/cordis (@​cordis/common)

v0.3.0

Compare Source

Hello! Been a while. 0.2 releases turned out to work much better than I thought they would. Cordis has seen quite the volume of use with some of the stuff I've been working on lately and it's just been going super well.

However, with that I managed to find a bunch of issues with rest rate limit handling - and oh lord. The codebase of that thing was a headache. This release is breaking because I have more or less entirely rewrote it.

Here's a list of changes:

  • [BREAKING] refactor(Rest#response): The response event was re-done. It now emits once the I/O call is done and gives you a clone of the response.
  • [BREAKING] refactor(Mutex#claim): no longer takes in a signal parameter, meaning you cannot cancel a request at this stage anymore - I'm fairly uncertain if this change really is desireable and it may see itself being reverted, but with a different approach. It was really only removed due to some of the problems it was causing
  • fix(HTTPError): no longer call Error.captureStackTrace(this); in the constructor - seems like this was causing some trouble, may make the stack traces work better now. Uncertain, but I'll continue bashing down on that problem over the next few patch releases
  • fix(Rest/Bucket): error handling - This should've been done ages ago, frankly. A lot of edge cases are now properly covered and recursion is no longer used for retries.
  • feat(DiscordFetchOptions#implicitAbortBehavior): tells the library if it should internally set a timeout for the actual I/O being done (fetch) - defaults to false if you pass in your own controller
  • feat(DiscordFetchOptions#retryAfterRatelimit): allows you to make 429 status codes just throw instead of wait & retry, defaults to Rest#retryAfterRatelimit.
  • feat(Rest#retryAfterRatelimit): default for the above

It's really not that bad. Unless you implemented your own mutex/did whacky stuff with the response event you don't even have to touch your code.


Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants