Skip to content

The Great Console Unification #7

Description

@nblumhardt

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:

  • All of the currently-available options in the three existing sinks:
    • Typical formatting options: message template or custom ITextFormatter, culture
    • Standard minimum level configuration
    • Minimum-level-to-STDERR
  • Palette control
    • By default, should look roughly like the current literate console (but we might update the color scheme, e.g. along the lines of VSCode?)
    • By default, uses ANSI color codes and make sure presentation is first-class in cmd.exe, bash (dark) and PowerShell (default blue) terminals
    • Custom ANSI and Windows palette implementations (LiterateConsole and ColoredConsole might use Windows ones by default, but we'd strongly encourage ANSI through docs/examples)
    • Selectable built-in "no color" palette
  • Support for {Properties}
  • Support for {Message:l} (this would probably be in the default template, since color would also be on by default, making property value delimiters (") redundant

Stretch/later goals:

  • Some level palette control via XML/JSON configuration (perhaps just choosing color/no-color, or palette-by-Type)

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?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions