I believe it rever really returned anything. It just wrote them on stdout.

It's not an API incompatibility.

It is a shift in the behavior of a side-effect though. Anyone who set up metric math based on log values here would be in for a surprise when they try to look at their reports.

This is definitely one of the gray areas when deciding whether or not to consider it a breaking change.

I agree it’s grey-area, but I’d lean towards calling it a breaking change, as it’s not too hard to imagine setups that would rely on a particular stdout format (e.g. some kind of log-parsing to generate an HTML report from an e2e test orchestration suite). But this is a major update, so breaking is fine anyway.

I think it’s ok, it’s just a debug statement that I think outputs to stderr. You should never be parsing it.

Shouldn't it be better to have a second function that spits out a formatted version? Or a parameter for a format. Or a parameter to switch between pretty and raw numbers?

no—this is something that likely shouldn't ever even be committed into a codebase. It's just something you throw in while testing to check why the performance of something is acting up.

The default is really important for something like this. Much more important than consistency.

You should not parse the stdout produced from console functions. It is for producing human-readable information. If you want machine-consumable data, you should use something like benchmark.js.

That's true of stderr output. You should be able to parse stdout though - otherwise how are you meant to use piping etc

How far we have strayed from the days where Unix tools were meant to be used as a stdlib, called through stdin and out. It makes me a little sad.

Classic HN comment on this topic: https://news.ycombinator.com/item?id=6530180

Not that far. Node has process.stdout/process.stdin/process.stderr. It's just that the console API is for debugging.

I looked at the code (but didnt try it) and I think this only affects console output, not any return value that you would parse.

Agreed. That's a ridiculous change.

A well defined function should have a single purpose, and a reliable and repeatable output.

It doesn't output back into your code though; it goes directly to stdout, so its main priority is readability for debugging. If you need log-quality output for parsing by another program there are plenty of libraries for getting time in whatever format you wish.

It's a function on `console`. It's meant to be human-readable, not machine-readable.

Console logging can be useful for eg being fed into Splunk from an ECS instance.

I don't do node.js so perhaps there are other ways of doing that specifically. (Works great in .net core)