Ensure ConsoleLogger logs the correct log level of the message

[martin-fleck-at]

What it does

• Ensure ConsoleLogger logs the correct log level of the message

How to test

• See that logged messages using different log levels (info, warn, ...) actually show the correct log level next to the logged message.

Follow-ups

Changelog

• This PR should be mentioned in the changelog
• This PR introduces a breaking change (if yes, provide more details below for the changelog and the migration guide)

[tortmayr]

Could you explain the reasoning behind this change?
I don't see why its necessary

[martin-fleck-at]

I think the previous logging was a bit unexpected, see for instance our log message:

// this.logger.info(`The GLSP server is ready to accept new client requests on port: ${currentPort}`);
The GLSP server is ready to accept new client requests on port: 5007 []

```ts
// this.logger.info('This is', 'just', 'a', ['test', 'message']);
This is [
    "just",
    "a",
    [
        "test",
        "message"
    ]
]

whereas with the fix it is more as I would expect it:

// this.logger.info(`The GLSP server is ready to accept new client requests on port: ${currentPort}`);
The GLSP server is ready to accept new client requests on port: 5007 

// this.logger.info('This is', 'just', 'a', ['test', 'message']);
This is "just",
"a",
[
    "test",
    "message"
]

What do you think?

[tortmayr]

I still don't get it. Looking at the current master, I get extactly the expected behavior you described:

3:09:06 PM info -  [SocketServerLauncher] The GLSP server is ready to accept new client requests on port: 5007 
3:09:06 PM info -  [SocketServerLauncher] This is "just",
"a",
[
    "test",
    "message"
]
[GLSP-Server]:Startup completed. Accepting requests on port:5007

The current implementation:

logAdditionals(...params: any[]): string {
        if (!params || params.length === 0) {
            return '';
        }
        return params.map(param => this.stringify(param)).join(',\n');
    }

also already as a guard check for empty/undefined arrays. So
The GLSP server is ready to accept new client requests on port: 5007 [] should never happen.

But what I'm more confused by is the special handling for arrays of index length 1.

[martin-fleck-at]

You probably used the WinstonLogger which does all of that already correctly! In any case, the real culprit was the missing spread when forwarding the params from the individual message calls (log, info, debug, etc.). Now it should behave more as expected. Please have another look.