zapslog stabilization tracking issue

[abhinav]

This issue tracks everything we need to do before zapslog can be moved to the main go.uber.org/zap module.

• zapslog.Handler: Add stack traces #1329
• zapslog.Handler: Test with slogtest, fix all failures #1334
• zapslog: Ensure adequate test coverage
• zapslog: Delete exp-based implementation #1337
• zapslog: Add a zapslog.Core that writes Zap logs to a slog.Handler
  • We may want to rename zapslog.Options to HandlerOptions when we do this.
• zapslog: Move to root Zap module #1270

Future features: Things we can add to it without risk after the initial availability:

• Support for a custom mapping of slog.Level to zap.Level

[arukiidou]

I would like to contribute zapslog GA.

zapslog: Add a zapslog.Core that writes Zap logs to a slog.Handler
We may want to rename zapslog.Options to HandlerOptions when we do this.

Can you tell us more about this?

[abhinav]

I would like to contribute zapslog GA.

zapslog: Add a zapslog.Core that writes Zap logs to a slog.Handler
We may want to rename zapslog.Options to HandlerOptions when we do this.

Can you tell us more about this?

Hello! Yes!

Okay, so right now, zapslog takes a Zap core, and returns a slog handler. func NewHandler(zapcore.Core) slog.Handler.
That's for applications that are already using Zap, and want to connect to a library that's using slog, to have the library feed their slog logs into their Zap handler.

The proposal was for the reverse: your application is using slog, and you want to use a library that uses Zap, so you want Zap to feed into your slog as the backend. Basically, func NewCore(slog.Handler) zapcore.Core.

Thinking about it out loud, though I don't know if this is actually necessary. @mway @prashantv @sywhang @r-hang What do y'all think?

On the second point: if this was added, then we'd want to rename the Option type to HandlerOption because we'd need another Option type (CoreOption) for the NewCore function.

One thing we could do is defer implementing NewCore until the need presents itself, but rename Option to HandlerOption anyway so that if/when that happens, we have the "option" name free.

[arukiidou]

• Is it means this?: zapslog: rename Option to HandlerOption #1411
  If so, it seems to me that I can submit this as a separate prs now.

That way we could move zapslog to the root module without having to change anything, and easier to migrate from exp for users.

[abhinav]

Yeah, I think following the rename, we can defer adding NewCore to when we need it.
That PR looks good! Thanks!

[arukiidou]

• Added zapslog: Support for a custom mapping of slog.Level to zap.Level #1413,
  please take a look? @abhinav