feat(cli): add progress bar to generation pipeline#680
feat(cli): add progress bar to generation pipeline#680shivxmsharma wants to merge 4 commits intonodejs:mainfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Pull request overview
Adds an optional CLI progress bar to the generation pipeline so users can see per-target generator completion while running doc-kit generate.
Changes:
- Introduces
src/utils/progressBar.mjs, a small wrapper aroundcli-progressthat renders tostderrand auto-disables whenstderrisn’t a TTY. - Hooks the progress bar into
src/generators.mjsso it starts after scheduling and increments once each target generator’s result collection finishes. - Adds
--no-progressto thegeneratecommand and wires it intorunGenerators, plus adds thecli-progressdependency.
Reviewed changes
Copilot reviewed 3 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| src/utils/progressBar.mjs | New utility to create a TTY-aware progress bar that writes to stderr. |
| src/generators.mjs | Starts/increments/stops the progress bar around target result collection. |
| bin/commands/generate.mjs | Adds --no-progress and passes opts.progress into the generator runner. |
| package.json | Adds cli-progress dependency. |
| package-lock.json | Locks cli-progress and its transitive dependencies. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
ca20ac3 to
4f07217
Compare
avivkeller
left a comment
There was a problem hiding this comment.
cc @ovflowd given that the tooling is really fast, is a progress bar still needed?
bin/commands/generate.mjs
Outdated
| errorWrap(async opts => { | ||
| const config = await setConfig(opts); | ||
| await runGenerators(config); | ||
| await runGenerators(config, opts.progress); |
There was a problem hiding this comment.
The progress bar should be a part of global config
There was a problem hiding this comment.
Should I wait for @ovflowd's response or make the possible changes to this?
There was a problem hiding this comment.
IMO progress bar should be disabled/enabled behind cli arg since it's related to cli.
4f07217 to
57a244e
Compare
|
Deployment failed with the following error: |
AugustinMauroy
left a comment
There was a problem hiding this comment.
LGMT ! and IMO it's still a good thing to have progress bar
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #680 +/- ##
==========================================
+ Coverage 74.74% 75.63% +0.89%
==========================================
Files 146 150 +4
Lines 13255 13725 +470
Branches 960 1040 +80
==========================================
+ Hits 9907 10381 +474
+ Misses 3342 3338 -4
Partials 6 6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
I think a progress bar/visual indicator is good regardless. Allows us to see on what it is working. I'd argue it should be behind a feature flag such as --progress if we make it opt-in or --no-progress if we make it opt-out. I'd argue opt-out by default would be ideal, so we can disable it on CI. It is a cool gimmick, but also genuinely brings "status" to what doc-kit is doing atm... Regardless of it being fast. What if I throw 20K md files on it? |
|
Hey @ovflowd, the current implementation already does this — @avivkeller the |
Co-authored-by: Aviv Keller <me@aviv.sh>
Co-authored-by: Aviv Keller <me@aviv.sh>
|
@avivkeller Committed the suggested changes! |
| return null; | ||
| } | ||
|
|
||
| return new SingleBar( |
There was a problem hiding this comment.
OOC, why this package versus other packages?
There was a problem hiding this comment.
Went with cli-progress mainly because of its large user base (~4M weekly downloads) and the simple API. It does exactly what we need without any extra bloat.
src/generators.mjs
Outdated
| await pool.destroy(); | ||
|
|
||
| return results; | ||
| try { |
There was a problem hiding this comment.
Done, reverted! 👍
src/generators.mjs
Outdated
| result = await streamingCache.getOrCollect(name, result); | ||
| } | ||
|
|
||
| progress?.increment({ phase: name }); |
src/generators.mjs
Outdated
| } | ||
|
|
||
| const progress = createProgressBar({ enabled: configuration.progress }); | ||
| progress?.start(generators.length, 0, { phase: 'Starting...' }); |
There was a problem hiding this comment.
If the user disabled the progress bar, it'll be undefined
There was a problem hiding this comment.
Ehh, I'd argue that
if (!enabled || !process.stderr.isTTY) {
return null;
}
Shouldn't be inside createProgressBar, what's the point of calling createProgressBar just to return null? Id recommend instead of not creating the instance, simply making a mock stream.
so:
import { PassThrough } from 'node:stream';
// ...
stream: shouldEnable ? process.stdout : new PassThrough();There was a problem hiding this comment.
Great suggestion, done! Now using a PassThrough stream when disabled instead of returning null. Much cleaner.
| "@rollup/plugin-virtual": "^3.0.2", | ||
| "@swc/html-wasm": "^1.15.18", | ||
| "acorn": "^8.16.0", | ||
| "cli-progress": "^3.12.0", |
There was a problem hiding this comment.
Last release was 3y ago, although I'm fine with not having releases that often, any particular reason why this package instead of others?
There was a problem hiding this comment.
It seems stable and mature — no breaking changes or open security issues. The last release is just because there's nothing to fix. Open to switching if you have a preference though!
ovflowd
left a comment
There was a problem hiding this comment.
This implementation of a ProgrressBar only provides Progress per generator, in the future we'd probably want to expose the Progress Bar as an Progress API to each generator so they can have more granular control.
Agreed, that would be a nice follow-up. Happy to work on that in a separate PR! |
Description
Adds a
cli-progressprogress bar to thegeneratecommand that tracks each target generator as it completes.src/utils/progressBar.mjsutility wrapscli-progressand writes tostderrto avoid conflicts with the existing logger (stdout)--no-progressflag to explicitly disable itThe bar starts after all generators are scheduled and increments once per target generator as its result collection finishes. The phase label shows the generator name:
Validation
All 312 existing tests pass.
Related Issues
Closes #58
Check List
npm run formatto ensure the code follows the style guide.npm testto check if all tests are passing.