Open
Description
We are planning to make the breaking changes below for ProgressBar
unstable API:
- BREAKING(cli/unstable): rename
ProgressBar
end()
method tostop()
#6406 - BREAKING(cli/unstable): make
ProgressBar
writable
optional #6409 - BREAKING(cli/unstable): make
ProgressBar
value
andmax
properties public #6430
The changes below could also be related:
Activity
kt3k commentedon Mar 21, 2025
I think we first need to settle on #6407 to start landing these changes
BlackAsLight commentedon Mar 21, 2025
On a somewhat related, somewhat different direction, both ProgressBar and Spinner have a flaw in their design in two ways.
I think their design needs to be reworked entirely to resolve these issues. I believe the first issue can be fixed by using some different terminal control sequences to move the cursor for rewrites instead of clearing the current line before writing again. For the second issue, I think it would be better if the APIs acted as if they were controlling some global state and not creating a piece of memory to be passed around. With this global state type of design, we could also allow more complex outputs in the terminal like multiple progress bars/ spinners or possibly even getting user input while a progress bar also updates on screen.
timreichen commentedon Mar 21, 2025
A few other things I noticed:
ProgressBarOptions.fmt
is an abbreviation which is not very web-apish. Maybe it should be called something likeformatter
orformat
instead.ProgressBarFormatter
seems overly complex atm.styledTime
andstyledData
seem like they could be getters instead of functions.ProgressBarFormatter
progressBar
,styledTime
andstyledData
should be strings without a trailing whitespaces.ProgressBarFormatter
properties #6502kt3k commentedon Apr 28, 2025
It seems difficult to reach agreement in #6407 and #6408
I'm considering to land only the first 3 (#6406, #6409, #6430) for now.
timreichen commentedon Apr 28, 2025
I have a radical proposal that might solve all these issues:
Let's rewrite parts of
ProgressBar
andProgressBarStream
:ProgressBar
sync and let it write totypeof Deno.stderr | typeof Deno.stdout
instead ofWritableStreamDefaultWriter
, likeSpinner
does.start()
only toProgressBar
like inSpinner
.ProgressBar
not useUnits
as a default value and style, because this is a very specialized case for downloads/streams. Rather make it a progress bar with1
as a defaultmax
.We also should check the behavior of
ProgressBarStream
.As of now we can do
This will create a progress bar that cannot be stopped.
WDYT?
kt3k commentedon Apr 30, 2025
I'm neutral about this. This change probably makes the implementation simpler, but also makes the stream version a bit less efficient because of blocking writes.
I'm against this change as stated in #6408. This introduces many edge case scenarios like restarting it after ended. That make implementation and testing unnecessarily complex.
It looks like this suggestion is only based on 'alignment' to web platform api (SpeechRecognition.start), but that argument seems to have counterexamples (WebSocket and Worker classes start main function at constructors)
Can you give example of progress bars which ends with max value 1? (In my view progress bar ranges are typically
0 to 100%
,0 to [MAX] bytes/files/whatever
. I don't remember progress bar ending with max = 1).kt3k commentedon May 20, 2025
I'm going to land the first 3