[BREAKING] Replace console.log with process.stderr

[d3xter666]

BREAKING CHANGE:
System messages will now be written to stderr instead of stdout.

JIRA: CPOUI5FOUNDATION-802
Related to: SAP/ui5-tooling#701
Sibling of: SAP/ui5-server#643, SAP/ui5-tooling#930

[coveralls]

coverage: 96.571% (+0.1%) from 96.432%
when pulling d707261 on breaking-v4
into 6a8c7a6 on main.

[flovogt]

@RandomByte what was the reason here when implementing the logging here not choosing ui5-logger?

[d3xter666]

@RandomByte what was the reason here when implementing the logging here not choosing ui5-logger?

My assumption is that we want "clear" messages and always to output something. This is the code in the logger:
https://github.com/SAP/ui5-logger/blob/d060f478b811fbf67f7452f60c9565f9fe01dab3/lib/loggers/Logger.js#L152

Basically, if the log level is silent, for example, nothing would occur and there will always be [info], [warning], etc. prepended in front of the message.

If my assumptions are invalid, please correct me and if there are no other objections, I'm perfectly fine to go with the @ui5/logger module

[RandomByte]

@RandomByte what was the reason here when implementing the logging here not choosing ui5-logger?

My assumption is that we want "clear" messages and always to output something. This is the code in the logger: https://github.com/SAP/ui5-logger/blob/d060f478b811fbf67f7452f60c9565f9fe01dab3/lib/loggers/Logger.js#L152

Basically, if the log level is silent, for example, nothing would occur and there will always be [info], [warning], etc. prepended in front of the message.

If my assumptions are invalid, please correct me and if there are no other objections, I'm perfectly fine to go with the @ui5/logger module

I'm pretty sure this is a relic from the time where @ui5/logger was based on npmlog. Messages where buffered so we feared that in case of an exception, our error log message would not be printed. Also the chalk formatting might have caused trouble since npmlog did its own formatting.

The fact that we used console.log (writing to stdout instead of stderr) was a mistake I think.

Yavor perfectly outlined the differences. But I somehow suspect that a user would expect that for log level "silent" we don't even log error messages.

If we don't see any technical issues with switching to @ui5/logger here, I would prefer that. Also see the internal PR I just referenced you in.

[matz3]

When I run ui5, I get this output (after fixing the broken import in init.js:

ui5
Command Failed:
Command Failed:
Command Failed:
Command Failed:
Command Failed:
Command Failed:
Command Failed:
Command Failed:
Command Failed:
Command required
Command required
Command required
Command required
Command required
Command required
Command required
Command required
Command required









See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'

Am I doing something wrong?

[RandomByte]

Yavor and myself just discussed this and came to the conclusion to revert back to directly writing the error messages to process.stderr.

This is already an improvement from before, where errors were written to stdout.

The main rational for not using @ui5/logger is the added [error] prefix in every line which reduces readability. The CLI is not intended to be consumed as a node module, so we can safely use process.stdout and stderr directly.

Some of the commands always write their output do stdout (ui5 tree) for example. So it's reasonable to have catched exceptions being written to stderr with the CLI's own formatting logic.

[d3xter666]

When I run ui5, I get this output (after fixing the broken import in init.js:

ui5
Command Failed:
Command Failed:
Command Failed:
Command Failed:
Command Failed:
Command Failed:
Command Failed:
Command Failed:
Command Failed:
Command required
Command required
Command required
Command required
Command required
Command required
Command required
Command required
Command required









See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'
See 'ui5 --help'

Am I doing something wrong?

It was just a try to provide cleaner messages for the Logger. It seems that if we want to achieve this via the Logger, the complexity of the code would increase. We discussed this with @RandomByte and it seems unreasonable to continue with that. Reverting back to process.stderr implementation instead.

[RandomByte]

Just went over the PR again. I think whenever we write the "main result" of a command, we should write it to stdout.

Any additional log messages as well as error messages should go to stderr. Basically anything that can't be parsed the same way as the standard output of the command.

[RandomByte]

Looks good to me and matches my expectations. Thanks!