log: support multiple outputs with independent formats (ANSI stdout + plain file)

[TerraTech]

Problem

In goa.design/clue/log (v1.2.3), logging configuration supports only a single output and a single formatter via:

log.Context(ctx,
    log.WithOutput(io.Writer),
    log.WithFormat(...),
)

This makes it impossible to achieve a very common production setup:

• ANSI-colored logs to stdout (terminal)
• Non-ANSI logs to a file (for grep / ingestion)

Using io.MultiWriter(os.Stdout, file) causes ANSI escape codes emitted by FormatTerminal to be written to the file as well.

There is currently no supported way to:

• attach multiple outputs, and
• configure different formats per output.

---

Expected behavior

A user should be able to express something equivalent to:

• stdout → FormatTerminal (ANSI)
• file → FormatText or FormatJSON (no ANSI)

without writing a custom io.Writer that strips ANSI codes.

---

Actual behavior

Only a single formatter is applied, so ANSI escapes always propagate to all outputs.

The only workaround in v1.2.3 is to implement a custom tee writer that:

• writes raw bytes to stdout
• strips ANSI before writing to file

This feels like something the logging library should handle.

---

Minimal repro

logFile, _ := os.OpenFile("app.log", os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0644)

mw := io.MultiWriter(os.Stdout, logFile)

ctx := log.Context(
    context.Background(),
    log.WithOutput(mw),
)

log.Info(ctx, "hello world")

Result:

• stdout: colored (expected)
• app.log: contains ANSI escape sequences (unexpected)

---

Proposed API (one of many options)

Any of the following would solve this cleanly:

// Option A: multi-output with per-output format
log.WithOutputs(
    log.Output{Writer: os.Stdout, Format: log.FormatTerminal},
    log.Output{Writer: logFile,  Format: log.FormatText},
)

// Option B: helper for common case
log.WithTerminalAndFile(os.Stdout, logFile)

// Option C: explicit NO_COLOR / disable color on non-terminals
log.WithNoColorFileOutput(logFile)

Exact shape is flexible — the key need is separating output destinations from formatting.

---

Context

This pattern exists in other Go logging ecosystems:

• zap (zapcore.NewTee)
• slog (HandlerGroup)
• go-kit/log (multi logger composition)

The lack of this capability in clue is surprising given its otherwise clean design.

[raphael]

That makes sense and the suggested extension looks good, a couple of thoughts:

1. We should make sure the proposal is backwards compatible so we'd probably keep the WithOutput and mark it as deprecated.
2. nit: I'm not sure we'd need the "NoColor" qualification in WithNoColorFileOutput, logging to a file implies no coloring, maybe just WithFile is enough and would mirror well WithTerminalAndFile - maybe that becomes WithFileAndTerminal foe additional consistency.

Would you be up to put together a PR?

[TerraTech]

Thank you for the response. I've been looking into my logging situation and I've decided to take a deeper dive into using log/slog and see if I can pattern it to my generalized needs. Four things I was most after, controlling colorized output, each output destination has specific handling, comprehensive "caller" logging, and context embedding.

I really like the easy ability with clue/log of the logger being embedded into the context as a core design (which slog can do even though you have to jump through a few hoops to accomplish it). I believe this is one of the nicest strengths of clue/log.

On the "caller" logging, I would mimic how hedzr/logex patterns it. I'll admit I started playing around with clue/log, as I was building a few microservices with goa. When I started to add a facade to it in my internal devel libraries, that is when I found out the "single output and a single formatter" limitation.

To be honest, I'm not 100% sure how best to architect the required changes to a PR. Looking at the situation now, it appears I can create a facade over log/slog to accomplish my goals.

As it stands now, I'll most likely just use clue/log while working within the goa ecosystem creating microservices and using a slog facade for my other generalized logging needs.

[raphael]

I put together #634 to implement the suggested behavior. Would love to hear your feedback on it!

[TerraTech]

Would the solution you propose benefit from an upcoming go 1.26 feature: https://antonz.org/go-1-26/#slog-multihandler?

I was going to revisit this when v1.26 was released.

Your PR does appear to resolve my issue. Even though I wrote a facade for logex, I ran into an impedance mismatch when I decided to wire in a goa design microservice (RESTful API handling) into a larger internal company project I was working on. I'm going to be doing a logging overhaul soon, and now that clue/log supports multiple output with independent(/custom) formats, the final obstacle has been resolved in order to baseline to clue logging.

Thank you.