effective-progress 0.7.0 → 0.8.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/README.md +8 -7
- package/dist/index.mjs +649 -737
- package/package.json +2 -1
package/README.md
CHANGED
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
[](https://www.npmjs.com/package/effective-progress)
|
|
4
4
|
|
|
5
5
|
> [!WARNING]
|
|
6
|
-
> Pre-`1.0.0`, breaking changes may happen in any release. SemVer guarantees will begin at `1.0.0`.
|
|
6
|
+
> Pre-`1.0.0`, breaking changes may happen in any minor release. SemVer guarantees will begin at `1.0.0`.
|
|
7
7
|
> I recommend using only the `Progress.all` and `Progress.forEach` APIs for now, as they will likely change the least. The lower-level APIs for manual progress bar control are more likely to see breaking changes as I iterate on the design.
|
|
8
8
|
>
|
|
9
9
|
> Please open an issue or reach out if you have any questions or want to contribute!
|
|
@@ -90,10 +90,11 @@ Support for `either`/`validate` modes of `Effect.all` and render the amount of s
|
|
|
90
90
|
- `examples/simpleExample.ts` - low-boilerplate real-world flow
|
|
91
91
|
- `examples/advancedExample.ts` - full API usage and manual task control
|
|
92
92
|
- `examples/mixedOutcomes.ts` - fail-fast vs `either`/`validate` with mixed success/failure counters
|
|
93
|
-
- `examples/cliProgressSemantics.ts` - zero totals, negative totals, overflow counts, and empty `all` / `forEach`
|
|
93
|
+
- `examples/cliProgressSemantics.ts` - zero totals, negative totals clearing to unknown totals, overflow counts, and empty `all` / `forEach`
|
|
94
94
|
- `examples/unknownTotalCounting.ts` - count successes/failures without a known total and render `processed/?`
|
|
95
95
|
- `examples/showcase.ts` - nested concurrent tasks, spinner workloads, and mixed Effect/Console logging
|
|
96
96
|
- `examples/performance.ts` - stress-style run with high log volume and deeply nested progress updates
|
|
97
|
+
- `examples/performanceLong.ts` - longer-running stress run with roughly 10x the work of `performance.ts`
|
|
97
98
|
|
|
98
99
|
## Configuration
|
|
99
100
|
|
|
@@ -111,9 +112,9 @@ Support for `either`/`validate` modes of `Effect.all` and render the amount of s
|
|
|
111
112
|
- Determinate amount text shows counters without prefixes: `<succeeded> <failed> <processed>/<total>`.
|
|
112
113
|
- Counts can exceed `total`; the amount text keeps those raw values (for example `12/10`) while the bar stays visually clamped at full.
|
|
113
114
|
- `total: 0` is valid for determinate tasks and renders as a full bar by default.
|
|
114
|
-
- Column widths are
|
|
115
|
+
- Column widths are measured and allocated per frame from a shared column tree, so rows stay aligned.
|
|
115
116
|
- Elapsed and ETA reserve stable widths to reduce jitter while tasks transition states.
|
|
116
|
-
-
|
|
117
|
+
- Sticky width can keep selected columns stable until the frame empties.
|
|
117
118
|
- On narrow terminals, layout compacts to fit available width and tree prefixes are suppressed when description space is too tight.
|
|
118
119
|
|
|
119
120
|
## Manual task control
|
|
@@ -136,10 +137,10 @@ const program = Progress.task(
|
|
|
136
137
|
);
|
|
137
138
|
```
|
|
138
139
|
|
|
139
|
-
Manual total behavior
|
|
140
|
+
Manual total behavior:
|
|
140
141
|
|
|
141
|
-
- negative totals on task creation
|
|
142
|
-
- negative totals on later `updateTask` calls
|
|
142
|
+
- negative totals on task creation clear the total and switch to indeterminate rendering
|
|
143
|
+
- negative totals on later `updateTask` calls also clear the total
|
|
143
144
|
- explicit `total: undefined` on `updateTask` clears the total and switches back to indeterminate rendering
|
|
144
145
|
|
|
145
146
|
## Column customization
|