You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we log bare strings in the Output Panel, when logging. Each log entry's string is manually prefixed with a timestamp and severity. The result looks like this:
But there's a better way to do it:
In the example above, the timestamp is automatically resolved, the text is parsed and colorized making it much more readable, and most importantly the severity is declaratively defined in a way that VS Code can parse it. This not only allows the user to set their desired log verbosity level
but also us as extension authors to log a lot more events (which could ease production debugging, issue reporting and reproduction) without fear that we will produce too much noice. Especially given the fact that there are more log levels than we're using now
Acceptance Criteria
our logs look like the nice image above, colorized, better timestamp etc
every successful shell command execution (i.e. using exec()) is logged by default, using trace level
care is taken to migrate each existing calls to exec() and keep logging things we already do while also not logging things we already don't want to log
logs are produced when a file or config watcher is triggered
logs are produced when a command is triggered
logs are produced when HTTP requests get sent
the above ACs are revisited to ensure they are sensible and also nothing else is missing
NOTES:
the earlier we do this the better logs we'll have in the long term because currently we're purposefully not logging things to reduce noise. If we could hide away things in trace or debug level then we'd definitely add more logs as we code stuff that we will probably not remember to cover if we do it after the fact
I understand that achieving the above involves changing
Currently, we log bare strings in the Output Panel, when logging. Each log entry's string is manually prefixed with a timestamp and severity. The result looks like this:
But there's a better way to do it:
In the example above, the timestamp is automatically resolved, the text is parsed and colorized making it much more readable, and most importantly the severity is declaratively defined in a way that VS Code can parse it. This not only allows the user to set their desired log verbosity level
but also us as extension authors to log a lot more events (which could ease production debugging, issue reporting and reproduction) without fear that we will produce too much noice. Especially given the fact that there are more log levels than we're using now
Acceptance Criteria
exec()
) is logged by default, usingtrace
levelexec()
and keep logging things we already do while also not logging things we already don't want to logNOTES:
the earlier we do this the better logs we'll have in the long term because currently we're purposefully not logging things to reduce noise. If we could hide away things in
trace
ordebug
level then we'd definitely add more logs as we code stuff that we will probably not remember to cover if we do it after the factI understand that achieving the above involves changing
but there's definitely a bit more to it.
this is where VS Code's built-in "log language" is defined, in case we want to leverage that to improve parsing/formatting https://github.com/microsoft/vscode/tree/main/extensions/log
when done it may be worth providing an answer to this SO question and help others in the community https://stackoverflow.com/questions/75764745/how-can-i-add-colorization-for-other-log-level-string-token-variations-in-vs-cod
The text was updated successfully, but these errors were encountered: