Deno: Console.log similar methods should have colors

[Skillz4Killz]

There are quite a few methods that do basically the same thing, such as console.log, console.info, console.warn ....

I would love if Deno had a slight user experience enhancement to them:

• log: logs without colors
• info: logs with blue color
• warn: logs with yellow color
• error: logs with red color
  etc...

Colors would help differentiate each type of log which would help debugging a ton!

[nayeemrmn]

console.error() is our idiomatic way of outputting strings to stderr. We can't "prettify" it extra characters. If we only applied colours to info() and warn() then maybe, but it just seems inconsistent at that point.

[sebastienfilion]

Shouldn't we just use stderr.write for low level stuff and use the log module for other complex things? I think that console.log (and maybe console.warn) should work like the browser as there is a precedent that was established and that's what people expect.
I understand that the issue is not that straightforward but I think it's a good way to see things as we move forward.

[nayeemrmn]

The browser behaviour you're talking about is actually the _inspector_ behaviour, which is shared between Deno and browsers (pending #4502). The fact that console.log() writes an encoded vanilla string to stdout is not taken from any web analogy. If we copied browsers, it would do nothing in the terminal and only write to the inspector.

[sebastienfilion]

I understand that. But my comment is in support of user experience and expectation.
But then again, it is true that, even with Node, console.error doesn't print in red from the terminal but it does through the inspector of my IDE. 🤔

[kitsonk]

But my comment is in support of user experience and expectation.

Wouldn't that be inconsistent with user experience and expectation on Node.js? That is a better set of expectations and precedence for server runtimes like Deno.

[sebastienfilion]

@kitsonk I think it's a valid argument. There are plenty of issues on here from people who wants "things like in Node"; but we resist those changes. Deno attracts a lot developers with Browser experience because of the API parity. That's why I think it's relevant to satisfies those expectation.
So the question is wether the decisions made for Node were the right one in retrospective or not.

[nayeemrmn]

Again, this isn't browser-parity vs Node-parity. Browsers write to the inspector. The server runtimes write to the inspector and standard streams. The fact that these functions write to standard streams at all, and the way values are formatted for standard streams, are not applicable in the browser and don't conflict with any browser behaviour. The only expectations surrounding this feature come from Node.

[sebastienfilion]

The fact that these functions write to standard streams at all, and the way values are formatted for standard streams, are not applicable in the browser and don't conflict with any browser behaviour.

I talked about user expectation which has nothing to do with a correct or incorrect implementation of the feature.

The only expectations surrounding this feature come from Node.

What does that mean? This issue was about colourizing the output of the different console level.
I don’t think it’s productive to say that we can’t change it because Node does it the other way. My point was simply that there was a precedent in user perception of what the console method does... I absolutely understand the separation of the standard stream vs the inspector.
I suspect that this suggestion will keep coming back if we don’t deal with it correctly...
In my opinion, the questions left to answer are:

1. Is this an actual improvement?
2. Would it break something fundamental if we implemented the change?
3. Is the cost of implementing this feature too expensive to justify it?

[nayeemrmn]

I don’t think it’s productive to say that we can’t change it because Node does it the other way.

My problem with the change was described here:

console.error() is our idiomatic way of outputting strings to stderr. We can't "prettify" it extra characters.

You brought up "user expectations" so Node was brought up in response.

[sebastienfilion]

You brought up "user expectations" so Node was brought up in response.

Yes. But both things can be true at the same time. Users will expect browser behaviour and will expect Node behaviour because of Deno's nature. So, is it objectively an improvement?

console.error() is our idiomatic way of outputting strings to stderr. We can't "prettify" it extra characters.

Are you saying that it is impossible or too expensive to implement?

[kitsonk]

There are plenty of issues on here from people who wants "things like in Node"; but we resist those changes.

It is a kind way of me saying I disagree with you. We do what we believe is best. I strongly believe writing console.log with colourisation should be to stdout and console.log and console.warn should log to stderr without ANSI colours as a default for Deno. The fact that Node.js aligns to this, and has set 10+ years of precedent for server side JavaScript is a pure bonus.

There is std/log for those who prefer a higher order more structured logging approach and quite a few 3rd party libraries as well.

[Skillz4Killz]

I strongly believe

Is there any reason for this? It's hard to understand without a good reason against it. Sorry if i missed it here but the only thing I've seen so far mentioned is it worsens user experience? I made this issue because it would improve my experience. I also see other users here who would also like this implying this can be good for user experience for them as well. I have yet to see anyone give a reason on how this would harm their experience.

console.log and console.warn should log to stderr

I'm not really sure what the benefits would be to moving these but if they are moved I agree it should not be colored. The only valid reason I can agree with is that stderr shouldn't be colored. If these methods are moved to log in stderr can we get other methods added that are sent to stdout which can be colored?

There is std/log for those who prefer a higher-order more structured logging approach and quite a few 3rd party libraries as well.

I think this might be hinting at a slight confusion here. Both the std/log and the 3rd party libraries are meant for logging. This feature request is meant for an improved debugging experience, not a logger built into deno. I mentioned this in detail in the discord channel, that for me this is important for debugging. I have my own custom logger in my projects, I don't need a logger but a better debugging experience.

I think I asked this in Discord, but as of right now these methods have 0 usefulness. Moving these to stderr would not really change that, they would still be doing the exact same thing which is basically just bloat. What harm will it do to add colors to these methods allowing them to have a unique and beneficial use case for easy debugging?

[sebastienfilion]

It is a kind way of me saying I disagree with you. We do what we believe is best.

You are allowed to disagree with me. No need to be kind about it.
I have to side with @Skillz4Killz and ask that we simply resolve this issue with a clear explanation of the reasoning behind this decision. Then we can come to agree, close this and refer to it when the question arises again in the future.

[timreichen]

Just as a comment watching from the sideline:
I agree with @Skillz4Killz and would like to see console method logs to be distinguishable.
I think it would be an enhancement since there is no real purpose in using different console methods at the moment because they all log the same.
About user expectation and node: When I first used node years ago I was expecting logs to be colored like in browser inspectors and was surprised that it didn't.

[sebastienfilion]

The conclusion from @nayeemrmn and @kitsonk objection can be shown with the following example. At the moment methods like log outputs to the stdout and method like error outputs to stderr.

// scratch.js
console.log("This is a log");
console.error("This is an error");

What that means is that if you wanted to write logs to one file and errors to another file, you'd do this:

deno run ./scratch.js > >(tee -a log) 2> >(tee -a errorlog)

And in your log file you'd have This is a log, and in your errorlog you'd have This is an error. Now if we were to add colours to the output, the error log would look like this  This is an error[39m, meaning that the file is difficult to parse now. So if we were to reroute all console method's output to stdout so we can colourize them, we'd be breaking one expectation.

Although this behaviour could be simply kept to the std/log module to handle, we're back at square one.

TLDR; Either it is kept to the std/log module to handle pretty print or to reroute errors to stderr. There's no way to make everyone happy.

[caspervonb]

So, console has always been weird. It isn't printf and it doesn't try to be printf but still we try to use it as printf.

Just want to point out that console already does presentation how it wants to, e.g this quotes and colorizes.

console.log("%o", "hello world");

[nayeemrmn]

Just want to point out that console already does presentation how it wants to, e.g this quotes and colorizes.

console.log("%o", "hello world");

Why does _that_ quote and colourise even though console.log("hello world") does not? Because console.log(<single string value>) is intended to be the primary way of writing a vanilla string to stdout (same with console.error()/stderr). The proposed change removes this assurance. If we did this we would need to move that functionality under a different API which doesn't seem worth it. It's a weird situation that this kind of log statement is handled uniquely, but convenient.

[timreichen]

Also:

console.log({ boolean: true });
console.error({ boolean: true });

will color true orange in deno and write { boolean: true } to both stdout and stderr.

[timreichen]

@kitsonk Just out of interest: Why does console.warn and console.error log to stderr instead of stdout? What advantage is there in comparison to Deno.stderr.writeSync(new TextEncoder().encode("some error"))? To me it would make more sense to have the different console methods be different appearance setups for stdout (like colors as discussed in this issue, or console.table).

[00ff0000red]

Just to pitch in another opinion:
...

I think it would be an enhancement since there is no real purpose in using different console methods at the moment because they all log the same.
I completely agree, between console.log, console.info, console.warn, and console.error, they are as good as equivalent. We might as well say

console.log = console.info = console.warn = console.error = ...;

There's simply no reason to prefer one over another. (Now, console.table and the rest are quite different and not comparable.)

About user expectation and node: When I first used node years ago I was expecting logs to be colored like in-browser inspectors and was surprised that it didn't.

I feel like this another opportunity for Deno to improve upon the decisions of the past. I wasn't using Node when it first came out, so I don't have 10 years worth of expectations, but when I arrived it just seemed lazy in a way to just log to stdout, leave it at that, and then say that it's equivalent to what you would expect from a browser. It simply doesn't cut it.
I believe that they should be as close as possible, the only exceptions I would expect are items in the console not being dynamic (ex: xmldir), not allowing you to press on the items in the console and copying them as global variables, etc, browser debugging features.