-
Notifications
You must be signed in to change notification settings - Fork 656
feat(rome_cli): add a --force-colors
argument
#3625
Conversation
✅ Deploy Preview for docs-rometools ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Parser conformance results on ubuntu-latestjs/262
jsx/babel
symbols/microsoft
ts/babel
ts/microsoft
|
Nice! What's your motivation behind introducing a new option rather than merging |
I think |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll leave the decision on having two options vs a single color
option to you.
Either way, please hold back with merging until after the 10.0.1 release as this is a new functionality according to semver
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do we plan to document the combination of --no-colors
and --force-colors
and how they work together? Having one options allows for better documentation, but two options requires better documentation (especially in the rome --help
command) to explain how they work together.
1285635
to
dc5ca27
Compare
Summary
Fixes #3623
This adds a new
--force-colors
argument to the CLI to force theEnvConsole
to use ANSI colors event if the stream would have otherwise been determined to be incompatible (not a TTY)Test Plan
I've added a few tests that ensure the
--no-colors
and--force-colors
arguments are correctly parsed, unfortunately it's not really possible to check they actually work since this relies on using the actualEnvConsole
instead of theMemoryConsole
and writes directly to the stdout / stderr streams usingtermcolor
, meaning it's not possible to inspect the output that got written by the CLI run (this also means the tests also circumvent theprintln!
inhibiting behavior of the Rust test framework and write directly to the test output anyway)