When sink emits on the console it always shows as coming from sink.ts rather than the originating location

[benjamind]

It would be nice to have a log output formatter that always emitting the call site file and line number rather than the sink.ts location. This makes debugging where a logging message came from infinitely easier.

See the screenshot on the readme for example https://raw.githubusercontent.com/dahlia/logtape/refs/heads/main/screenshots/web-console.png

[dahlia]

Thank you for reporting this issue! I've investigated the feasibility of preserving call site information in browser consoles.

The core problem

Browser DevTools show the file/line where console.log() is actually called. In LogTape's architecture, this happens inside the sink, not in your application code. This is fundamental to how browser consoles work with the JavaScript call stack.

Is it solvable?

Complete solution: No. As long as LogTape uses its sink architecture, the DevTools clickable link will always point to the sink. The only library that solves this is loglevel, which uses Function.prototype.bind() to avoid wrapper functions entirely—but it doesn't support structured logging, sinks, or formatters.

Partial solution: Yes. We could:

1. Capture call site info using Error.stack when creating LogRecords
2. Add a sourceLocation field to LogRecord
3. Display the location in the formatted message itself:

   12:34:56 [myfile.ts:42] INF my-app This is a log message
   

This makes the location visible in the log output, but the DevTools link would still point to the sink.

Trade-offs

• Performance cost: Creating Error objects for every log
• Runtime differences: Stack trace formats vary across Deno/Node.js/Bun/browsers
• Minification: May be inaccurate in production builds
• Message length: Adds extra text to every log line

Question

Would this partial solution (showing location in the message text) be valuable enough to justify the trade-offs? Other major structured logging libraries like Pino and winston don't attempt this either, though they primarily target server-side Node.js rather than browsers where this issue is more prominent.

I'm happy to work on a PR if you think this would be useful despite the limitations.

[benjamind]

Yes i think this might be something worth having as a 'dev' mode option? Perhaps only compiled in when using the development module resolution?

[dahlia]

That's a great idea! Having this as a dev mode option would address the performance concerns nicely.

Implementation approach

This would require changes at two levels:

1. Logger level: Capture call site info when creating LogRecords (using Error.stack)
2. Console sink level: Display the captured call site in the formatted message

So we'd need two separate options:

configure({
  sinks: { 
    console: getConsoleSink({
      showCallSite: true,  // Whether to display call site in message
    })
  },
  loggers: [
    {
      category: "my-app",
      level: "debug",
      sinks: ["console"],
      captureCallSite: true,  // Whether to capture call site (dev mode only)
    }
  ]
});

The captureCallSite option would need to be implemented in the Logger class itself, not just the sink, because we need to capture the stack trace at the point where the log record is created. If we try to capture it later in the sink, the stack would be too deep to find the original caller.

This also means the call site info would be available in the LogRecord's properties, so other sinks (file, structured logging, etc.) could use it too if needed.

One clarification

Just to make sure we're aligned: even with this feature, the DevTools clickable link would still point to sink.ts (this is unavoidable). The call site info would only appear in the message text itself, like:

12:34:56 [myapp.ts:42] INF my-app This is a log message

Is that acceptable for your use case? The location would be visible and easy to find, but you'd need to navigate to it manually rather than clicking the DevTools link.