-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
Conversation
Review requested:
|
The subsystem here shouldn't be test, it should be lib |
Thanks @RedYetiDev, I was not sure about this, gonna change it! |
test/parallel/test-runner-output.mjs
Outdated
{ | ||
name: 'test-runner/output/non-tty-forced-color-output.js', | ||
flags: ['--test-reporter=spec'], | ||
}, |
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.
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.
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.
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.
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.
Also, should this change be considered a breaking change since it changes the evident behaviour?
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.
IMO it's not breaking, it's a bug fix
57e19b4
to
05ae05f
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
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
|
Regarding #52249, I would say we have two ways to ensure the fix:
Given node/lib/internal/test_runner/harness.js Lines 66 to 69 in e2242b4
I believe this PR should resolve both issues, as you suggest 😁. Personally, I would go with option 1. WDYT @RedYetiDev @cjihrig |
I'd go with 1 |
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.
lgtm
Option 1 sounds good. |
}, | ||
{ | ||
name: 'test-runner/output/assertion-color-tty.mjs', | ||
flags: ['--test', '--stack-trace-limit=0'], |
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.
Hey @cjihrig, I had to add the --stack-trace-limit=0
flag because modifying
node/test/common/assertSnapshot.js
Lines 7 to 9 in 4d6d7d6
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?
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.
Yes, that's fine IMO.
60cb508
to
28a532e
Compare
While working on the tests I've seen this behaviour: import assert from 'node:assert/strict'
import { test } from 'node:test'
test('failing assertion', () => {
assert.strictEqual('apple', 'pear')
}) Honestly I've mixed feelings about this from a devEx pov. @nodejs/test_runner @nodejs/assert |
28a532e
to
dd82e49
Compare
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; |
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.
Non-blocking and admittedly more verbose (and I know not introduced in this PR) but I'd generally prefer something like the following instead.
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; | |
} |
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.
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 😁
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.
The CI is green now, maybe consider doing a follow up PR (I agree with suggested change though).
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 agree, also because I have the impression that osx CI has been a little unstable in the last two days
Landed in 025d8ad |
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>
PR-URL: nodejs#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>
This PR should address #55383.