console: adhere to environment variables enforcing colors

[BridgeAR]

Make sure the console color auto mode checks the environment
variables if any enforces (de)activation of colors.

Fatal errors will also check for the environment variables from now on.

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

[addaleax]

This check should not be dropped.

[BridgeAR]

The intention of this PR is to circumvent this check. This is a semver-major PR to adhere to the environment variables. Those should always come first, no matter what kind of stream is used. Otherwise it's not possible to fully (de)activate colors using environment variables.

[addaleax]

Those should always come first, no matter what kind of stream is used.

I’m -1 on this, sorry. Console instances should be as self-contained as possible, relying on external state like environment variables is counterintuitive imo and breaks orthogonality.

Otherwise it's not possible to fully (de)activate colors using environment variables.

Right, but I don’t think that should be the case. Custom Console instances should adhere to their options and nothing else.

[BridgeAR]

This will only change the behavior under the following circumstances:

Colors will not be printed anymore when deactivated with environment variables (FORCE_COLOR, NODE_DISABLE_COLORS, NO_COLOR) for TTY streams that do not have a getColorDepth() function.

Colors will be printed when activated with the FORCE_COLOR environment variable for all streams.

[addaleax]

Colors will be printed when activated with the FORCE_COLOR environment variable for all streams.

Right – what I’m saying is that I’m -1 on this specifically (because, again, that breaks orthogonality).

[BridgeAR]

Right, but I don’t think that should be the case. Custom Console instances should adhere to their options and nothing else.

Using a boolean for the color option will do exactly that. It's only about the auto mode which ideally checks for the users intent. Using an environment variable is a clear indicator for the user to request a specific mode.

I’m -1 on this, sorry. Console instances should be as self-contained as possible, relying on external state like environment variables is counterintuitive imo and breaks orthogonality.

But it's still going to be self-contained? The current behavior seems counter-intuitive to me. I would expect environment variables to clearly have an impact on default values. It is one of the strongest possible ways a user is able to request a general behavior.

---

I'll open a twitter survey to get a bigger opinion pool.

We often use environment variables to override the default value. This is what is also suggested here.

[devsnek]

I think Anna's point is that there's no inherent connection between the stream a Console is using and the process's env (they are orthogonal), so even if the mode is auto, using data from the env is nonsensical.

[Mikael-Lovqvist]

Hey, sorry to necrobump, but I really don't follow the reasoning behind console checking whether a stream is a TTY before calling the getColorDepth function if it exists and is a function. Why does it matter that the environment is orthogonal to the console when the responsibility to determine if colors should be used are handed off to the getColorDepth function? In my own testing I noticed that if isTTY is dropped from the condition I get colored output when piping to a non TTY despite not setting FORCE_COLOR so there is more to it than just dropping that part of the expression to get a behavior that corresponds to my interpretation of the manual.

[Mifrill]

I've just сame across the discussion regarding the proposed change to the console color auto mode, and I'd like to express my support for the modification.

The goal of ensuring that the console color auto mode considers environment variables for (de)activating colors is a valuable one.

Here's why I believe this change is beneficial:

Clarity and Predictability: When users set environment variables like FORCE_COLOR, NODE_DISABLE_COLORS, or NO_COLOR, they have a clear intention regarding color output. By checking these variables, the console can align itself with the user's preferences.

User Empowerment: Allowing users to control color output through environment variables empowers them to customize their development environment to suit their needs. It's in line with the philosophy of "configuration over convention."

Consistency: This change promotes consistency by ensuring that environment variables take precedence. Regardless of the stream type (TTY or non-TTY), the user's color preferences are respected.

I believe that by implementing this change, the console becomes more versatile and user-friendly. While it's essential to maintain self-contained behavior in most cases, it's equally important to provide flexibility to accommodate diverse development environments and individual preferences.

Ultimately, using environment variables to influence default behaviors is a common practice in many software projects. It's a powerful way for users to communicate their intent and align tools with their expectations.