GeezerVison

I am fine with this, but I checked the "spec" and it says nothing regarding the output. Its even worse, LOL

See

https://console.spec.whatwg.org/#table

I am fine with this, but I checked the "spec" and it says nothing regarding the output. Its even worse, LOL

See

https://console.spec.whatwg.org/#table

Yeah. The WHATWG, is not suppose mention the standards in very detail. They have the links to MDN.

Yes and the mdn does not state that the entries are left aligned but just contains a screenshot.

What was the original reason for centering it in Node.js? Is there a git blame?

I have the feeling this might break some stuff based on snapshots/benchmarks

CI: https://ci.nodejs.org/job/node-test-pull-request/55236/

CI: https://ci.nodejs.org/job/node-test-pull-request/55265/

Landed in 14af167

AFAICT the change is only visual.

Output changes are considered semver-major. Marco tagged it because we've just mentioned it during the collab summit.

It hasn't released yet. Thanks for catching up @marco-ippolito.

Update: Wait, if this is now following the SPEC I wonder if this should be considered semver-major.

There is no SPEC, now it just has the same behavior of browser

AFAICT the change is only visual.

Output changes are considered semver-major. Marco tagged it because we've just mentioned it during the collab summit.

I don’t think that’s true, for example changing an error message technically changes the output, yet we don’t consider it semver-major. Also the output of console.table is not observable from JavaScript without watching directly the stdout.

I don’t think that’s true, for example changing an error message technically changes the output, yet we don’t consider it semver-major

We do consider error message changes as semver-major or at least, we should.

@RafaelGSS that's not what we say in our documentation:

AFAICT, it's always been the case that we have been treating error message update as semver-patch, and recommend users to use the code property to detect errors.

Anyway, to come back to this PR, I really think this is not semver-major, but it's not a hill I'll die on.

Oh, I haven't seen or I don't remember these sections, thanks for pointing that out. If we have a doc or a precedence, I won't object to it. @marco-ippolito I will remove the label. In case you strong believe it should be semver-major, ping me.

FWIW a resource I found in a quick search #3374.

UPDATE: It was discussed when error.code didn't exist at the time (that is what I understood from this discussion: https://github.com/nodejs/node/pull/4664/files#diff-bbed55d3167db7c16baf3ee2c51acb1b09f7740ab1399ab015226c3df488753aR46). So it's not a fair discussion.

The reason why we have this entire error.code system (and a former strategic initiative involving years of work assigning these codes) was to prevent having to treat error.message changes as server major. Only errors that are known to have their messages captured in the user land (mostly system errors) can still get the semver major treatment but otherwise error message changes are considered semver patch.

I believe @mcollina mentioned output changes in console were semver major.
I'm not sure the comparison it's fair between error.message and console.table,
console.table is widely used for benchmarks and snapshots, in documentation etc..., the output actually matters.
but I'm not gonna insist if it's something documented

output changes can breaking. Maybe let's await backporting to LTS for a bit?

This should likely not have been backported to v20, it broke our tests.
It also broke Undici tests.

This should likely not have been backported to v20, it broke our tests.
It also broke Undici tests.

Can we clearly add to the documentation that console output changes should be semver major?