Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

util: detecting terminal capabilities in styleText #51959

Closed
wants to merge 1 commit into from

Conversation

edsadr
Copy link
Member

@edsadr edsadr commented Mar 4, 2024

This PR adds some detection of the process configuration for printing colors when using util.styleText

@nodejs-github-bot nodejs-github-bot added needs-ci PRs that need a full CI run. util Issues and PRs related to the built-in util module. labels Mar 4, 2024
@RafaelGSS RafaelGSS added the request-ci Add this label to start a Jenkins CI on a PR. label Mar 4, 2024
@github-actions github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Mar 4, 2024
@nodejs-github-bot
Copy link
Collaborator

@@ -204,6 +204,12 @@ function pad(n) {
* @returns {string}
*/
function styleText(format, text) {
const env = process.env;
if (!process.stdout.isTTY ||
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please use shouldColorize from internal/util/colors, it takes all these into account but also the actual color depth of the tty.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will follow this suggestion based on the feedback for my proposal below

@@ -204,6 +204,12 @@ function pad(n) {
* @returns {string}
*/
function styleText(format, text) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we add this we probably want to pass a force parameter (not an env var)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

@@ -204,6 +204,12 @@ function pad(n) {
* @returns {string}
*/
function styleText(format, text) {
const env = process.env;
if (!process.stdout.isTTY ||
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure it's the right thing to systematically look at process.stdout. styleText, as an utility function, should not (always) depend on that.

Copy link
Member

@RafaelGSS RafaelGSS Mar 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean the user should perform this check by themselves?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When using such a utility, you aren't necessarily writing on to stdout. You might be writing to a file, and you might want to use coloring even without a tty

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a fair point.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about adding a boolean parameter to the function set to true by default to check the TTY: styleText(format, text, validateTTY)? So we offer the option to use the function with or without the proposed validation?

The idea behind this validation is to provide the mechanism by default to Node users, saving them time with some code that would be a must in the most common use case of this utility function.

I will be waiting for your feedback, @targos and @MoLow to implement such suggestion

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM

Copy link
Contributor

This issue/PR was marked as stalled, it will be automatically closed in 30 days. If it should remain open, please leave a comment explaining why it should remain open.

@RedYetiDev
Copy link
Member

@edsadr are you still planning to persue this?

@RafaelGSS
Copy link
Member

I will work on that. Possibly in a different PR.

@RafaelGSS
Copy link
Member

Closing in favour of #54389

@RafaelGSS RafaelGSS closed this Aug 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-ci PRs that need a full CI run. stalled Issues and PRs that are stalled. util Issues and PRs related to the built-in util module.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants