Log using process.stderr.write instead of console.error since this isn't an error

[sidharthachatterjee]

As a result of c3b1df6#diff-168726dbe96b3ce427e7fedce31bb0bc, updates appear as errors for gatsby (and other projects that depend on yurnalist I think)

However, I do understand the need to put this in stderr as opposed to stdout, so how do we feel about replacing console.error here with a call to process.stderr.write?

If this makes sense, we're happy to open a PR and get this patched! Thank you

[sindresorhus]

console.error is the same as process.stderr.write expect for the added newline.

console.error - Prints to stderr with newline. - https://nodejs.org/api/console.html#console_console_error_data_args

The fact that Gatsby treats it as error sounds like a bug in Gatsby. stderr is just an alternative stream, not necessarily only for errors.

[pieh]

(disclaimer I'm one of the gatsby maintainers)

console.error is the same as process.stderr.write expect for the added newline.

This is true, implementation wise in Node.js.

I think it's worth to mention that console.error vs other console methods have semantic meaning when using it in web context, where messages have their level marked and you can use it to filter console messages:

I know that web isn't target for this package, but we are hoping to use same convention as web in gatsby to visually mark some messages as errors in terminal output - as shown in screenshot in the issue description (so it's easier for users to spot messages in output that could be pretty long in some cases).

The fact that Gatsby treats it as error sounds like a bug in Gatsby. stderr is just an alternative stream, not necessarily only for errors.

We don't check what stream is used, just which console method is used - that's why we propose using process.stderr here directly instead of console.error which will preserve behavior.

I'm not super excited about hijacking console.error in gatsby, but that's really only way to get message levels from 3rd party packages don't use our logging APIs (specifically when those packages are being used as dependencies in gatsby or one of gatsby plugins and gatsby is not only usecase for them)