How should terminal metadata be exposed?

[CanadaHonk]

Terminal metadata idea from this #1 comment.

• Should we have a parent object (eg CLI.terminal.noColor) or bare in the namespace (eg CLI.noColor)?
• Functions (eg CLI.terminal.noColor()) or getters (eg CLI.terminal.noColor)?
• Interactivity:
  • Potential names: interactive, isInteractive, interactivity, nonInteractive, notInteractive, tty, isTty, isTTY, terminal, isTerminal, inTerminal
  • Deno used to have a isatty(...) function, but now is moving to isTerminal.
• No color:
  • Potential names: noColor, color, colorful, hasColor, shouldColor
  • We should probably just use noColor as it is essentially an opt-out preference; color could imply the user wants color which could not be true (rather than NO_COLOR stating the user explicitly does not want color). Also, this would then share the name of the environment variable "standard".
  • Only Deno exposes just this (Deno.noColor) afaik, other runtimes you have to handle it yourself (eg !!process.env.NO_COLOR).

[Im-Beast]

Regarding NO_COLOR:
On the opposite side of NO_COLOR is FORCE_COLOR, definitely less known, but respected by some big npm packages, e.g. chalk and supports-color.
I don't think there's described behavior about connecting FORCE_COLOR and NO_COLOR, so this is kind of ambiguous.

I'm definitely against names hasColor or colorful (both imply that terminal can display color).
I don't see having both noColor and forceColor as an issue though.

[paperdave]

a boolean flag for if color is supported ignores that some terminals support different amounts of color detail. for example, the npm package supports-color has four levels of color support to determine what set of colors are supported. though, these checks are very heuristics based and standardizing it would probably be a micro-nightmare.