From serilog-archive/serilog-sinks-literate#17.
We've now had experience with three different console sink designs, this one, ColoredConsole and LiterateConsole.
Each has strengths and weaknesses; for example, literate has nice presentation, but Console can accept a custom formatter and produce valid JSON if required.
It's time to unify all of these. There are, as always, options. A strawman proposal:
- Extend this sink (Serilog.Sinks.Console) so that it supports everything we would like it to (as a 3.0/breaking change release)
- Make Serilog.Sinks.ColoredConsole and Serilog.Sinks.LiterateConsole into thin wrappers around Serilog.Sinks.Console that configure it with default palettes/formatting options to achieve (mostly?) the original output of those sinks
- Mark
WriteTo.LiterateConsole() and WriteTo.ColoredConsole(), and the corresponding NuGet packages, obsolete, directing users to WriteTo.Console()
Things I think we want without doubt:
Stretch/later goals:
Other thoughts:
- Do we want to keep using the default "Serilog-style" rendering of things like dictionaries and
StructureValue, or would the output be more predictable/meaningful for people if we instead printed complex values as (syntax-highlighted) JSON?
From serilog-archive/serilog-sinks-literate#17.
We've now had experience with three different console sink designs, this one,
ColoredConsoleandLiterateConsole.Each has strengths and weaknesses; for example, literate has nice presentation, but
Consolecan accept a custom formatter and produce valid JSON if required.It's time to unify all of these. There are, as always, options. A strawman proposal:
WriteTo.LiterateConsole()andWriteTo.ColoredConsole(), and the corresponding NuGet packages, obsolete, directing users toWriteTo.Console()Things I think we want without doubt:
ITextFormatter, culturecmd.exe,bash(dark) andPowerShell(default blue) terminalsLiterateConsoleandColoredConsolemight use Windows ones by default, but we'd strongly encourage ANSI through docs/examples){Properties}{Message:l}(this would probably be in the default template, since color would also be on by default, making property value delimiters (") redundantStretch/later goals:
Type)Other thoughts:
StructureValue, or would the output be more predictable/meaningful for people if we instead printed complex values as (syntax-highlighted) JSON?