microsoft/vscode-languageserver-node

VSCode language client should configure logger pointing to the output channel rather than console

Open

#1,613 opened on Feb 8, 2025

View on GitHub
 (2 comments) (0 reactions) (0 assignees)TypeScript (397 forks)auto 404
feature-requesthelp wanted

Repository metrics

Stars
 (1,776 stars)
PR merge metrics
 (PR metrics pending)

Description

I recently received a user report of a bug in my language server, but the expected error log did not show in the configured output channel as I expected. Typically I direct users to look into this output channel when reporting issues.

I happened to find the error after I opened Developer: Toggle Developer Tools and saw the error log in the developer console, rather than the output channel:

The logged error was a Received response message without id, and looking at the code this comes from a call to logger.error:

https://github.com/microsoft/vscode-languageserver-node/blob/d810d51297c667bd3a3f46912eb849055beb8b6b/jsonrpc/src/common/connection.ts#L909

Logger is configurable, and after looking around I found that the client configures the logger as a ConsoleLogger, which is why it ends up going to the developer console:

https://github.com/microsoft/vscode-languageserver-node/blob/d810d51297c667bd3a3f46912eb849055beb8b6b/client/src/common/client.ts#L2409

What do you think about changing this to log into the vscode output channel rather than the console? I believe this will make the logs more visible for debugging

Contributor guide

Research direction
Investigate how the client currently sets up the logger (see client.ts line 2409) and learn how to create a VSCode OutputChannel logger that writes to a designated output channel instead of using the console. Look for existing examples in the codebase or VSCode API documentation.
Tech stack
typescriptnodejs
Domain
developer experiencetooling
Issue type
Bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
GitTypeScript
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
75