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

assert,tty: fix indicator and warning #31429

Conversation

BridgeAR
Copy link
Member

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), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

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.
@nodejs-github-bot nodejs-github-bot added assert Issues and PRs related to the assert subsystem. tty Issues and PRs related to the tty subsystem. labels Jan 20, 2020
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@BridgeAR BridgeAR requested review from Trott and richardlau February 6, 2020 19:55
@BridgeAR
Copy link
Member Author

BridgeAR commented Feb 9, 2020

This could use another review. @nodejs/assert @nodejs/testing @nodejs/tty PTAL

@BridgeAR
Copy link
Member Author

BridgeAR commented Feb 9, 2020

Landed in 1450ea7...63f10b9 🎉

@BridgeAR BridgeAR closed this Feb 9, 2020
BridgeAR added a commit to BridgeAR/node that referenced this pull request Feb 9, 2020
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]>
BridgeAR added a commit to BridgeAR/node that referenced this pull request Feb 9, 2020
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]>
BridgeAR added a commit to BridgeAR/node that referenced this pull request Feb 9, 2020
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]>
codebytere pushed a commit that referenced this pull request Feb 17, 2020
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]>
codebytere pushed a commit that referenced this pull request Feb 17, 2020
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]>
codebytere pushed a commit that referenced this pull request Feb 17, 2020
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]>
@codebytere codebytere mentioned this pull request Feb 17, 2020
@vladimyr
Copy link

@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

codebytere pushed a commit that referenced this pull request Mar 15, 2020
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]>
codebytere pushed a commit that referenced this pull request Mar 15, 2020
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]>
codebytere pushed a commit that referenced this pull request Mar 15, 2020
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]>
codebytere pushed a commit that referenced this pull request Mar 17, 2020
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]>
codebytere pushed a commit that referenced this pull request Mar 17, 2020
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]>
codebytere pushed a commit that referenced this pull request Mar 17, 2020
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]>
@codebytere codebytere mentioned this pull request Mar 17, 2020
codebytere pushed a commit that referenced this pull request Mar 30, 2020
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]>
codebytere pushed a commit that referenced this pull request Mar 30, 2020
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]>
codebytere pushed a commit that referenced this pull request Mar 30, 2020
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assert Issues and PRs related to the assert subsystem. tty Issues and PRs related to the tty subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants