@zap-studio/retry 1.2.0 → 1.2.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +6 -0
- package/README.md +10 -0
- package/package.json +10 -4
package/CHANGELOG.md
CHANGED
|
@@ -4,6 +4,12 @@ All notable changes to this project will be documented in this file.
|
|
|
4
4
|
|
|
5
5
|
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
|
6
6
|
|
|
7
|
+
## [1.2.1]
|
|
8
|
+
|
|
9
|
+
### Changed
|
|
10
|
+
|
|
11
|
+
`@zap-studio/logger` is now an optional peer dependency instead of a regular dependency. Every import from it is type-only (`import type { Logger }`), so it was never pulled in at runtime — pass any object matching the `Logger` shape (including `pino`) with no install required. Existing consumers of `logger?: Logger` are unaffected.
|
|
12
|
+
|
|
7
13
|
## [1.2.0]
|
|
8
14
|
|
|
9
15
|
### Added
|
package/README.md
CHANGED
|
@@ -4,6 +4,16 @@ Composable retry policy primitives for HTTP clients and async workflows.
|
|
|
4
4
|
|
|
5
5
|
Full documentation: [zapstudio.dev/retry](https://www.zapstudio.dev/retry)
|
|
6
6
|
|
|
7
|
+
## Motivation
|
|
8
|
+
|
|
9
|
+
A hand-written retry loop is usually a `for` loop with `setTimeout`, and it is easy to get wrong in ways that only show up under load. Without jitter, every client that lost connection to a service retries at the exact same moment once it comes back, causing a new spike right when the service is trying to recover.
|
|
10
|
+
|
|
11
|
+
Without cancellation, a retry loop can keep running — and keep hitting the network — after the result is no longer needed, for example after a user navigates away.
|
|
12
|
+
|
|
13
|
+
`@zap-studio/retry` gives you this behavior as a built-in option, instead of something you write from scratch. `exponentialBackoff` and `linearBackoff` support jitter (`"full"` or `"equal"`, the same strategies AWS recommends) through the `jitter` option — turn it on and delays are randomized instead of fixed.
|
|
14
|
+
|
|
15
|
+
Every retry loop also accepts an `AbortSignal`, checked before each attempt and while waiting between attempts, so an abort stops the next attempt or delay from starting; it does not interrupt an attempt that is already running. You get retry policies as values you configure once and reuse, instead of logic you have to get right from scratch in every project.
|
|
16
|
+
|
|
7
17
|
## Installation
|
|
8
18
|
|
|
9
19
|
```bash
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@zap-studio/retry",
|
|
3
|
-
"version": "1.2.
|
|
3
|
+
"version": "1.2.1",
|
|
4
4
|
"private": false,
|
|
5
5
|
"description": "Composable, tree-shakeable retry policies for resilient async operations.",
|
|
6
6
|
"keywords": [
|
|
@@ -43,15 +43,21 @@
|
|
|
43
43
|
"publishConfig": {
|
|
44
44
|
"access": "public"
|
|
45
45
|
},
|
|
46
|
-
"dependencies": {
|
|
47
|
-
"@zap-studio/logger": "1.0.0"
|
|
48
|
-
},
|
|
49
46
|
"devDependencies": {
|
|
50
47
|
"tsdown": "^0.22.14",
|
|
51
48
|
"typescript": "^7.0.2",
|
|
52
49
|
"vitest": "^4.1.10",
|
|
50
|
+
"@zap-studio/logger": "1.0.0",
|
|
53
51
|
"@zap-studio/typescript": "0.0.0"
|
|
54
52
|
},
|
|
53
|
+
"peerDependencies": {
|
|
54
|
+
"@zap-studio/logger": "1.0.0"
|
|
55
|
+
},
|
|
56
|
+
"peerDependenciesMeta": {
|
|
57
|
+
"@zap-studio/logger": {
|
|
58
|
+
"optional": true
|
|
59
|
+
}
|
|
60
|
+
},
|
|
55
61
|
"engines": {
|
|
56
62
|
"node": ">=18.0.0"
|
|
57
63
|
}
|