Open
Conversation
Introduce ui-renderer.ts to handle renderOptionHelp and renderFooter. This replaces ad-hoc logger.raw calls in the help syntax branch with structured OptionHelpData. Key changes: - Added #renderOptions() bridge method. - Implemented automatic documentation URL generation based on option flags. - Improved help output styling and consistency. Manual testing verified via: - npx webpack help --config - npx webpack help -c
Enhance help output for short flags (e.g., -c, -d) by implementing a 'renderAliasHelp' banner.This displays a styled ⬡ <alias> → <canonical> header above the option details to clearly distinguish aliases from primary options. - Provides immediate visual context when users request help for shorthand commands.
Introduce renderCommandHelp to ui-renderer.ts and migrate Commander Command data into the structured CommandHelpData format. Key architectural changes: - Replaced helpInformation() calls with renderCommandHelp for consistent styling. - Added a preAction hook in makeCommand to intercept '--help' before action execution, preventing side effects (e.g., 'watch' starting during help). - Centralized self-exit logic for all help paths (global, command, option). - Removed legacy trailing footer blocks in favor of integrated renderer footers.
Standardize command lifecycle with renderCommandHeader and contextual footers/status glyphs (✔ / ✖ / ⚠). Key enhancements: - build/watch: Deferred header/footer logic ensures visual chrome wraps the actual stats output with timing summaries. - serve: Integrated header/error handling into the DevServer validation lifecycle. - version/info: Replaced raw output with styled alignment, colored tables, and arrow-mapped resolutions. - configtest: Added semantic success, warning, and error reporting for validated files. - runWebpack: Introduced headerFn callback for granular control over emission timing relative to compiler events.
…pshots Comprehensive test suite addition for ui-renderer.ts Changes: - Added unit tests for all UI. - Updated existing CLI integration snapshots. - Added new snapshots for command-specific renders (version, info, and configtest etc..).
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
As discussed in my previous PR #4723 , this update overhauls the design of the webpack-cli output. The primary goal is to standardize the interface by replacing ad-hoc logging with a structured, data-driven approach to headers, footers, and command metadata.
What kind of change does this PR introduce?
it's a feature, introuce a new UI for the cli
New-CLI-DEMOS.mp4
Did you add tests for your changes?
Does this PR introduce a breaking change?
Technically, yes, because the output format has changed. However, since the UI is now fully decoupled from the core CLI logic, it is much more stable for future development. Changes to the "guts" of the CLI won't accidentally break the UI, and vice-versa.
If relevant, what needs to be documented once your changes are merged or what have you already documented?
I’ve added comments throughout the code to explain the new logic. I’m not sure if we need to update the official external documentation for these internal UI changes yet, but I am open to suggestions if you think it's necessary!
Use of AI
for commit description, some JSDoc comments