refactor(cli/unstable): remove `previousTime` and `previousValue`

[timreichen]

I don't see why they should be provided by the formatter object. These values can easily be stored and accessed in variables as is demonstrated in the test that is removed.

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 94.71%. Comparing base (e10c71a) to head (d3fc89c). :warning: Report is 97 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6660      +/-   ##
==========================================
- Coverage   94.71%   94.71%   -0.01%     
==========================================
  Files         567      567              
  Lines       46778    46770       -8     
  Branches     6582     6582              
==========================================
- Hits        44305    44297       -8     
  Misses       2431     2431              
  Partials       42       42              

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[BlackAsLight]

I don't agree with this change as these values are needed if one wants the progress bar to display the rate of progress being made. Forcing users to create additional variables to achieve this seems like a bad design choice.

[timreichen]

I don't agree with this change as these values are needed if one wants the progress bar to display the rate of progress being made. Forcing users to create additional variables to achieve this seems like a bad design choice.

Could you give an example how that would look like? I compared it to cli-progress which doesn't provide previous values in formatter, so I thought this is probably very niche.

[BlackAsLight]

Could you give an example how that would look like? I compared it to cli-progress which doesn't provide previous values in formatter, so I thought this is probably very niche.

A rate like x mb/s. Essentially these values makes it easy for you to communicate the speed at which progress is being made.

[===-------] [2 MiB/s]

[timreichen]

Could you give an example how that would look like? I compared it to cli-progress which doesn't provide previous values in formatter, so I thought this is probably very niche.

A rate like x mb/s. Essentially these values makes it easy for you to communicate the speed at which progress is being made.

[===-------] [2 MiB/s]

Ah, I see. Would it make sense to have the speed as a separate property instead the need to calculate it by hand? Maybe a delta that can be formatted into a unit? [${formatUnit(delta)}/s]? I think std would profit by a public UnitFormatter anyway.

[timreichen]

stale