Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34.4k
assert,tty: fix indicator and warning#31429
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
assert,tty: fix indicator and warning #31429
Uh oh!
There was an error while loading. Please reload this page.
Conversation
This makes sure color codes are not taken into account in case util.inspect's default value was changed.
Make sure the assertion is actually triggered by using `assert.throws()` instead of `try/catch`.
It was possible that this warning ends up in an infinite recursion. The reason is that printing the warning triggered a color check and that triggered another warning. Limiting it to a single warning prevents this.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
nodejs-github-bot commented Jan 25, 2020
nodejs-github-bot commented Jan 26, 2020
nodejs-github-bot commented Jan 26, 2020
BridgeAR commented Feb 9, 2020
This could use another review. @nodejs/assert @nodejs/testing @nodejs/tty PTAL |
BridgeAR commented Feb 9, 2020
Landed in 1450ea7...63f10b9 🎉 |
This makes sure color codes are not taken into account in case util.inspect's default value was changed. PR-URL: nodejs#31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Make sure the assertion is actually triggered by using `assert.throws()` instead of `try/catch`. PR-URL: nodejs#31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
It was possible that this warning ends up in an infinite recursion. The reason is that printing the warning triggered a color check and that triggered another warning. Limiting it to a single warning prevents this. PR-URL: nodejs#31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
This makes sure color codes are not taken into account in case util.inspect's default value was changed. PR-URL: #31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Make sure the assertion is actually triggered by using `assert.throws()` instead of `try/catch`. PR-URL: #31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
It was possible that this warning ends up in an infinite recursion. The reason is that printing the warning triggered a color check and that triggered another warning. Limiting it to a single warning prevents this. PR-URL: #31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
vladimyr commented Feb 29, 2020
@BridgeAR How do you feel about tweaking it a bit for sake of readability? I guess it is slightly less performant but if you are fine with tradeoff I can do a quick PR with proposed changes. diff --git a/lib/internal/tty.js b/lib/internal/tty.js index 44d5173700..3e0da04890 100644 --- a/lib/internal/tty.js+++ b/lib/internal/tty.js@@ -26,6 +26,7 @@ const{ERR_INVALID_ARG_TYPE, ERR_OUT_OF_RANGE } = require('internal/errors').codes; +const{Boolean } = primordials; let OSRelease; @@ -77,23 +78,21 @@ let warned = false; function warnOnDeactivatedColors(env){if (warned) return; - let name = '';- if (env.NODE_DISABLE_COLORS !== undefined)- name = 'NODE_DISABLE_COLORS';- if (env.NO_COLOR !== undefined){- if (name !== ''){- name += "' and '";- }- name += 'NO_COLOR';- }- if (name !== ''){- process.emitWarning(- `The '${name}' env is ignored due to the 'FORCE_COLOR' env being set.`,- 'Warning'- );- warned = true;- }+ const name = [+ env.NODE_DISABLE_COLORS !== undefined && '\'NODE_DISABLE_COLORS\'',+ env.NO_COLOR !== undefined && '\'NO_COLOR\''+ ].filter(Boolean).join(' and ');++ if (!name)+ return;++ process.emitWarning(+ `The ${name} env variable is ignored due to the 'FORCE_COLOR' env ` ++ 'variable being set.',+ 'Warning'+ );+ warned = true; } // The `getColorDepth` API got inspired by multiple sources such as |
This makes sure color codes are not taken into account in case util.inspect's default value was changed. PR-URL: #31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Make sure the assertion is actually triggered by using `assert.throws()` instead of `try/catch`. PR-URL: #31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
It was possible that this warning ends up in an infinite recursion. The reason is that printing the warning triggered a color check and that triggered another warning. Limiting it to a single warning prevents this. PR-URL: #31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
This makes sure color codes are not taken into account in case util.inspect's default value was changed. PR-URL: #31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Make sure the assertion is actually triggered by using `assert.throws()` instead of `try/catch`. PR-URL: #31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
It was possible that this warning ends up in an infinite recursion. The reason is that printing the warning triggered a color check and that triggered another warning. Limiting it to a single warning prevents this. PR-URL: #31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
This makes sure color codes are not taken into account in case util.inspect's default value was changed. PR-URL: #31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Make sure the assertion is actually triggered by using `assert.throws()` instead of `try/catch`. PR-URL: #31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
It was possible that this warning ends up in an infinite recursion. The reason is that printing the warning triggered a color check and that triggered another warning. Limiting it to a single warning prevents this. PR-URL: #31429 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Please have a look at the commit messages. I can split this into two PRs but I stumbled upon both things at the same time and they seemed small enough that individual commits might suffice.
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes