-
Notifications
You must be signed in to change notification settings - Fork 29.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: document console changes as breaking #51503
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,6 +19,7 @@ | |
* [Breaking changes](#breaking-changes) | ||
* [Breaking changes and deprecations](#breaking-changes-and-deprecations) | ||
* [Breaking changes to internal elements](#breaking-changes-to-internal-elements) | ||
* [Breaking changes to console APIs](#breaking-changes-to-console-apis) | ||
* [Unintended breaking changes](#unintended-breaking-changes) | ||
* [Reverting commits](#reverting-commits) | ||
* [Introducing new modules](#introducing-new-modules) | ||
|
@@ -354,6 +355,7 @@ Examples of breaking changes include: | |
* Adding or removing errors. | ||
* Altering expected timing of an event. | ||
* Changing the side effects of using a particular API. | ||
* Changing the output of some [console APIs](#breaking-changes-to-console-apis). | ||
|
||
#### Breaking changes and deprecations | ||
|
||
|
@@ -378,6 +380,20 @@ an effort to determine the potential impact of the change in the ecosystem. Use | |
If a change will cause ecosystem breakage, then it is semver-major. Consider | ||
providing a Public API in such cases. | ||
|
||
### Breaking changes to console APIs | ||
|
||
Console APIs are a debugging tool, and the format of their output should generally not | ||
be considered stable. | ||
However due to the nature of the Node.js ecosystem, users rely on stability of | ||
the output of some of these APIs for snapshot testing, parsers, etc... | ||
To avoid breaking changes, some behaviors should be considered stable. | ||
The following changes in the output are to be considered breaking changes: | ||
|
||
* `console.table` (padding, alignment, etc...). | ||
* changing the color of all console methods. | ||
* changing the signature of all console methods. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The signature is as-stable as every other API call and the rest aren't stable (are they?) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I dont know if the signature is considered stable but not the output, if its obvious Im gonna remove it |
||
* changing the output for single string inputs. | ||
|
||
#### Unintended breaking changes | ||
|
||
Sometimes, a change intended to be non-breaking turns out to be a breaking | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this is less about the color (visual appearance when connected to a TTY) and more about the contract of outputting raw strings unmodified to the output stream when piped (without adding additional control sequences).
The visual color of the output can change easily as
util.inspect()
is evolved and doesn't matter for interactive use, but a lot of users rely onconsole.error(str)
orconsole.log(str)
to outputstr
untouched toprocess.stderr
/process.stdout
, e.g. for logging JSON in production.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to be fair
process.stdout
/stderr
.write()
has always been available to use for these needs and additionally gives control over whether a newline is inserted. The pain is around correcting all the code that needs this changed. One might argue it to be superior to make a NEW set of console or other APIs that could gain features like this and maybe steadily enhance those features over time.I have to assume that this was the whole point of the console interface from the beginning... After all, it has slick stuff like
console.table()
that everyone knows not to rely on its implementation specific properties.I am just as guilty myself for opting to use
console.error
instead ofprocess.stderr.write
. This situation seems unavoidable