Deep debugger integration

[npdev453]

In my case, when pino is used with vscode debugger (vscode-js-debugger) logs are missed, but it can be fixed with "outputCapture": "std" in the launch configuration.

However, when "outputCapture": "std" is used, the debugger sometimes randomly combine different logs (1-20) into one output record, as shown in the screenshot below:
(Mouse hovered at "2")

This behavior makes it impossible to use VSCode filters feature in debugger console (especially when dealing with large amounts of prettified logs combined into one):

(This issue also reproduces when using pure console.log, so I believe this is nature of the std.)

I noticed that there was a tool called pino-inspector in the past, it was not designed as well as it should have been, in my opinion:

1 - It shouldn't function as a serializer, it could be a pipeable transformer transport, similar to pino-syslog, to provide more flexibility.
2 - Instead of just redirecting everything to inspector.console.* it could emit Runtime.consoleAPICalled events with context and stackTrace to indicate the line from which the logs were originally sent (which is currently not possible with pino). (or with args to make objects foldable, don't know).
3 - It should have its own place in the documentation, particularly in the Inspection section.
4 - It should not check inspector.url() because it's empty when VSCode debugger is attached.

---

Repro:

    const logger = pino();
    logger.info('1');
    logger.info('2');
    logger.info('3');
    console.log('1');
    console.log('2');
    console.log('3');

launch.json

{
    "configurations": [
        {
            "name": "Launch Program",
            "program": "${workspaceFolder}/index.js",
            "request": "launch",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "outputCapture": "std",
            "type": "node"
        }
    ]
}

[mcollina]

We currently do not have the bandwidth to implement or maintain this. Would you like to work on this problem?

We can start a new repo or unarchive pino-inspector

[npdev453]

@mcollina, sure, but currently I'm not in resource to tackle with technical or ecosystem barriers. I'll need consultative help to effectively deal with it.

~ Roadmap:

• v0. Just Runtime.consoleAPICalled Transport
  Simply emits on any logs or levels.

• v1. Log Levels
  Find a way to pass raw log level to the transport (if it's in the pipeline) to send it correctly to Runtime.consoleAPICalled

• v2. Stacktraces
  Find a way to detect and pass stacktace to the transport (mixin? monkey-patch?). For example upper before logger.info call.

• v3. Errors (?)
  Currently, stacktraces in Debug Console are not interactive, jump to code in traces does not work (microsoft/vscode#34026). This can be temporarily fixed if the error object is passed separately in Runtime.consoleAPICalled

[mcollina]

I can't really help with the VSCode/Inspector part, but happy to answer questions on pino itself.

[npdev453]

@mcollina,
I was specifically asking about Pino. Could you please provide some advice regarding the points above?