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

lib: ensure FORCE_COLOR forces color output in non-TTY environments #55404

Merged
merged 5 commits into from
Oct 23, 2024

Conversation

pmarchini
Copy link
Member

This PR should address #55383.

@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/test_runner

@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 Oct 16, 2024
@RedYetiDev
Copy link
Member

The subsystem here shouldn't be test, it should be lib

@pmarchini
Copy link
Member Author

Thanks @RedYetiDev, I was not sure about this, gonna change it!

Comment on lines 206 to 209
{
name: 'test-runner/output/non-tty-forced-color-output.js',
flags: ['--test-reporter=spec'],
},
Copy link
Member

@RedYetiDev RedYetiDev Oct 16, 2024

Choose a reason for hiding this comment

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

Instead of testing the test runner, IMO add a test where a non-TTY FORCE_COLOR is used.

This change isn't specific to the test runner

Although, I had some weird test failures when doing that (unrelated to the change, more how the test was setup), so if that's not possible, this works.

Copy link
Member Author

Choose a reason for hiding this comment

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

You’re right, I added the test to cover the fix for the specific issue.
We should add tests to cover every use.
But does it make sense, considering we would be adding tests to parts of the codebase that are "out of scope"? Also, I wouldn't feel confident about the quality of the tests I’d add in this way.

Copy link
Member Author

Choose a reason for hiding this comment

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

Also, should this change be considered a breaking change since it changes the evident behaviour?

Copy link
Member

Choose a reason for hiding this comment

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

IMO it's not breaking, it's a bug fix

@pmarchini pmarchini changed the title test: ensure FORCE_COLOR forces color output in non-TTY environments lib: ensure FORCE_COLOR forces color output in non-TTY environments Oct 16, 2024
Copy link

codecov bot commented Oct 16, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.41%. Comparing base (b0ffe9e) to head (dd82e49).
Report is 32 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #55404      +/-   ##
==========================================
- Coverage   88.42%   88.41%   -0.01%     
==========================================
  Files         653      653              
  Lines      187498   187496       -2     
  Branches    36100    36103       +3     
==========================================
- Hits       165791   165783       -8     
- Misses      14957    14960       +3     
- Partials     6750     6753       +3     
Files with missing lines Coverage Δ
lib/internal/util/colors.js 100.00% <100.00%> (ø)

... and 24 files with indirect coverage changes

@RedYetiDev RedYetiDev added the lib / src Issues and PRs related to general changes in the lib or src directory. label Oct 16, 2024
@RedYetiDev
Copy link
Member

Fixes #55383
Fixes #52249

@lpinca lpinca added the request-ci Add this label to start a Jenkins CI on a PR. label Oct 16, 2024
@github-actions github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Oct 16, 2024
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@RedYetiDev RedYetiDev added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Oct 16, 2024
@nodejs-github-bot
Copy link
Collaborator

@pmarchini
Copy link
Member Author

Fixes #55383 Fixes #52249

Regarding #52249, I would say we have two ways to ensure the fix:

  1. Add a test in this PR to confirm that the issue is indeed resolved.
  2. After this PR gets merged, open another PR with a test to ensure the fix and close the issue.

Given

counters: null,
shouldColorizeTestFiles: shouldColorizeTestFiles(globalOptions.destinations),
teardown: null,
snapshotManager: null,

I believe this PR should resolve both issues, as you suggest 😁.

Personally, I would go with option 1.

WDYT @RedYetiDev @cjihrig

@RedYetiDev
Copy link
Member

I'd go with 1

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

lgtm

@cjihrig
Copy link
Contributor

cjihrig commented Oct 17, 2024

Option 1 sounds good.

},
{
name: 'test-runner/output/assertion-color-tty.mjs',
flags: ['--test', '--stack-trace-limit=0'],
Copy link
Member Author

Choose a reason for hiding this comment

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

Hey @cjihrig, I had to add the --stack-trace-limit=0 flag because modifying

const stackFramesRegexp = /(?<=\n)(\s+)((.+?)\s+\()?(?:\(?(.+?):(\d+)(?::(\d+))?)\)?(\s+\{)?(\[\d+m)?(\n|$)/g;
const windowNewlineRegexp = /\r/g;

to match colored stack traces also seems a little painful.

Do you think it's acceptable?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, that's fine IMO.

@pmarchini
Copy link
Member Author

pmarchini commented Oct 17, 2024

While working on the tests I've seen this behaviour:
image
This comes from this recently merged PR #54862.

import assert from 'node:assert/strict'
import { test } from 'node:test'

test('failing assertion', () => {
  assert.strictEqual('apple', 'pear')
})

results in:
image

Honestly I've mixed feelings about this from a devEx pov.

@nodejs/test_runner @nodejs/assert

@pmarchini pmarchini added the request-ci Add this label to start a Jenkins CI on a PR. label Oct 18, 2024
@github-actions github-actions bot added the request-ci-failed An error occurred while starting CI via request-ci label, and manual interventon is needed. label Oct 18, 2024
Copy link
Contributor

Failed to start CI
   ⚠  Something was pushed to the Pull Request branch since the last approving review.
   ✘  Refusing to run CI on potentially unsafe PR
https://github.com/nodejs/node/actions/runs/11397893999

@jakecastelli jakecastelli added the request-ci Add this label to start a Jenkins CI on a PR. label Oct 18, 2024
@github-actions github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Oct 18, 2024
@nodejs-github-bot
Copy link
Collaborator

@RedYetiDev RedYetiDev removed the request-ci-failed An error occurred while starting CI via request-ci label, and manual interventon is needed. label Oct 20, 2024
Comment on lines +27 to +36
const hasColors = module.exports.shouldColorize(process.stderr);
module.exports.blue = hasColors ? '\u001b[34m' : '';
module.exports.green = hasColors ? '\u001b[32m' : '';
module.exports.white = hasColors ? '\u001b[39m' : '';
module.exports.yellow = hasColors ? '\u001b[33m' : '';
module.exports.red = hasColors ? '\u001b[31m' : '';
module.exports.gray = hasColors ? '\u001b[90m' : '';
module.exports.clear = hasColors ? '\u001bc' : '';
module.exports.reset = hasColors ? '\u001b[0m' : '';
module.exports.hasColors = hasColors;
Copy link
Member

@jasnell jasnell Oct 20, 2024

Choose a reason for hiding this comment

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

Non-blocking and admittedly more verbose (and I know not introduced in this PR) but I'd generally prefer something like the following instead. 

Suggested change
const hasColors = module.exports.shouldColorize(process.stderr);
module.exports.blue = hasColors ? '\u001b[34m' : '';
module.exports.green = hasColors ? '\u001b[32m' : '';
module.exports.white = hasColors ? '\u001b[39m' : '';
module.exports.yellow = hasColors ? '\u001b[33m' : '';
module.exports.red = hasColors ? '\u001b[31m' : '';
module.exports.gray = hasColors ? '\u001b[90m' : '';
module.exports.clear = hasColors ? '\u001bc' : '';
module.exports.reset = hasColors ? '\u001b[0m' : '';
module.exports.hasColors = hasColors;
if (module.exports.shouldColorize(process.stderr)) {
module.exports.blue = '\u001b[34m';
module.exports.green = '\u001b[32m';
module.exports.white = '\u001b[39m';
module.exports.yellow = '\u001b[33m';
module.exports.red = '\u001b[31m';
module.exports.gray = '\u001b[90m';
module.exports.clear = '\u001bc';
module.exports.reset = '\u001b[0m';
module.exports.hasColors = true;
} else {
module.exports.blue = '';
module.exports.green = ';
module.exports.white = ';
module.exports.yellow = ';
module.exports.red = '';
module.exports.gray = '';
module.exports.clear = '';
module.exports.reset = '';
module.exports.hasColors = false;
}

Copy link
Member Author

Choose a reason for hiding this comment

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

Hey @jasnell, thanks for the review.
I don't have strong opinions on this specific case, but in general, I think the more readable, the better.

We would have some repetitions, but I think it would be worth it.

Up to you 🚀 If you want, I can use this PR to address this readability issue as well 😁

Copy link
Contributor

@jakecastelli jakecastelli Oct 22, 2024

Choose a reason for hiding this comment

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

The CI is green now, maybe consider doing a follow up PR (I agree with suggested change though).

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 agree, also because I have the impression that osx CI has been a little unstable in the last two days

@pmarchini pmarchini added the request-ci Add this label to start a Jenkins CI on a PR. label Oct 21, 2024
@github-actions github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Oct 21, 2024
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@pmarchini pmarchini added commit-queue-squash Add this label to instruct the Commit Queue to squash all the PR commits into the first one. commit-queue Add this label to land a pull request using GitHub Actions. labels Oct 22, 2024
@nodejs-github-bot nodejs-github-bot removed the commit-queue Add this label to land a pull request using GitHub Actions. label Oct 23, 2024
@nodejs-github-bot nodejs-github-bot merged commit 025d8ad into nodejs:main Oct 23, 2024
63 checks passed
@nodejs-github-bot
Copy link
Collaborator

Landed in 025d8ad

aduh95 pushed a commit that referenced this pull request Oct 23, 2024
PR-URL: #55404
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Jake Yuesong Li <jake.yuesong@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. commit-queue-squash Add this label to instruct the Commit Queue to squash all the PR commits into the first one. lib / src Issues and PRs related to general changes in the lib or src directory. needs-ci PRs that need a full CI run. util Issues and PRs related to the built-in util module.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants