Remove logging framework

[vwkd]

I'd suggest to remove the log module.

It isn't cross platform compatible, has the lowest JSR score of all @std packages with 88%, and is still unstable. The API has not evolved since originally porting it from Go, the API doesn't really fit JavaScript with magical global state that's influenced by the setup function, which the user must take care to always call first before any implementing library.

It's the only framework in the standard library. There are different ways to do a framework and not one best solution. There are various third-party frameworks, often better maintained and cross platform. Frameworks aren't a good fit for a standard library.

It's why a HTTP framework wasn't added multiple times https://github.com/denoland/std/pull/144#issuecomment-457255712 https://github.com/denoland/std/pull/1555#issuecomment-1142390942. Related #1295.

[iuioiua]

I agree. I very much dislike @std/log. Discussions with Yoshiya (when I maintained this project) aligned with replacing the entire package with something better.

[halvardssm]

I partially agree, I don’t mind the logger changing, but I am finding it very useful to have a standard logger library that can log to the console, a file and whatever pluggable custom logger I would find or make.

[BlackAsLight]

I am in favour of it being changed instead of removed. I'm not 100% familiar with how it works, but things I'd like to see in a logging framework is:

• The ability for libraries to implement it in their code that doesn't add additional computational strait if the main module isn't using it.
  • This could maybe be archived though accepting simple types in log.debug() or any type that implements a custom symbol like Symbol.Log, where calling the symbol on the object will have it handle how to stringify the object.
• For the main module to decide completely how the output of the logger is displayed instead of opting for JSON.
• A cron like expression that triggers to allow rotation of where the logs are going. For example if it's going to a file, lets one switch to a new file after x hours.
• Many of the settings for the main module be configured via environment variables. This can remove people's disdain for the need to call log.setup() Like:
  • Default level being logged.
  • Library specific level being logged.
  • Location the logs are logged: "stdout", "stderr", a directory/file name, "null", or let runtime code decide.

[chyzwar]

What is the best alternative? Last time I tried to use pino it was not working. As user, I would want to know what is recommended logging framework in deno.

[kt3k]

LogTape seems relatively popular to me https://github.com/dahlia/logtape It officially supports Deno, and is available from JSR https://jsr.io/@logtape/logtape

[chyzwar]

Logtape is not even a year old and only have one maintainer. It only has 510 stars. For me, this is the definition of niche and very early stage. Is there is a way see download stats in JSR?

[timreichen]

The question I asked myself lately is if there is some middleground. I dislike the setup procedure and global state but find myself using a custom implementation of ConsoleLogger a lot, where one can set a debug loglevel based on dev or prod so the built in console can be avoided. Maybe we could provide such building blocks and get rid of the other stuff so people can build log frameworks around them?

[iuioiua]

Logtape is not even a year old and only have one maintainer. It only has 510 stars. For me, this is the definition of niche and very early stage. Is there is a way see download stats in JSR?

I think if the quality of the design is good enough, the package is good enough to be adopted anyway.

[chyzwar]

I think if the quality of the design is good enough, the package is good enough to be adopted anyway.

I disagree. The maintainer could disappear tomorrow, and you will end up with hundreds of call sites to a library that is no longer maintained. Logtape support both structured logging and lazy evaluation these features are in my opinion are bad ideas and need to be carefully evaluated if you do not want to have another Log4Shell moment.

For me the biggest benefit of Deno is DX. When you use Deno you no longer need to pick random quality libraries. You have a great standard library that can cover common use cases. Things like logger are fundamental to developing of any application. I suspect that logger is one of the more used packages from std.

[kt3k]

Last time I tried to use pino it was not working.

pino now seems working to me in Deno (The below worked):

import pino from "npm:pino";
const logger = pino();
logger.info("hello world");
const child = logger.child({ a: "property" });
child.info("hello child!");

pino seems great in its support policy https://github.com/pinojs/pino/blob/main/docs/lts.md

[chyzwar]

pino now seems working to me in Deno (The below worked):

Not on Windows: https://github.com/pinojs/pino/issues/2060 Deno is not officially supported by pino it works only because improved node.js compact (can break any moment)

In my opinion, there is no production ready logger for Deno.

As stand today there is no production

[kt3k]

Note: We are making OpenTelemery builtin to Deno runtime https://docs.deno.com/runtime/fundamentals/open_telemetry/

[kt3k]

Side note: pino's file transport compatibility was fixed in https://github.com/denoland/deno/pull/27378

[alexgleason]

I created a custom JSON "logger" framework after reading this thread, much in the spirit of Vanilla JS: https://jsr.io/@soapbox/logi 🤣

[funnylookinhat]

I think there is something to be said for the ergonomics of a log solution, and that most users expect logging solutions to drive them towards some sort of consistency in the fields they adopt. At a bare minimum, I think most users expect to be able to import {debug, info, warn, error} from "@some/package" - or have some similar convention with a method that returns those.

What I like about the built-in @std/log package (that OpenTelemetry does not solve) is the ability to dump meaningful messages for development and debugging to the console. I could do without the INFO > prefixes and whatnot - and would prefer to rely on providing a baseline log level to filter what it shown depending on what the use case is. I've also really appreciated the @std/log package for building simple libraries, utilities, and formatted console dumping depending on the scenario.

I like the idea of a very minimal logger like @alexgleason provided - but for me to adopt it for a team I'd have to wrap it with another layer of configuration and exposed methods to ensure some level of consistency and configurability.

The logtape package is nice - and doesn't feel overly complex for the solution it provides. It has nice abstractions for logging implementation in "library" scenarios (also for how you may structure a large repository), and has just enough configuration that I could see it being ready to use for a team on day 1. The extra sink configuration feels excessive to me - routing logs is really the responsibility of the OS.

I think there would be value in having the @std/log package maintained and updated to keep a meaningful baseline log solution available and ready to use. I don't think it needs to be very much (in fact, it shouldn't be!), but there should be something.

[BlackAsLight]

I'd also like the continuation of @std/log. I figured out a cool way to have ignored logs have very little overhead with short circuiting.

import { delay } from "@std/async";
import { info } from "@std/log";

info?.("Hello World");

info?.(async function () {
  await delay(1000);
  return "Bye World";
}());

Essentially at startup info will either be a function that accepts a string or Promise<string> or be undefined and just skipped over very fast.

[funnylookinhat]

Here's something I created as a thought experiment from this thread.

https://jsr.io/@funnylookinhat/logosaurus

[dahlia]

Hi everyone, I'm the author of LogTape. I noticed some concerns about LogTape in this discussion that I'd like to address.

Regarding security concerns

Logtape support both structured logging and lazy evaluation these features are in my opinion are bad ideas and need to be carefully evaluated if you do not want to have another Log4Shell moment.

This comparison isn't technically accurate. The Log4Shell vulnerability was possible because Log4j would interpret and execute strings in log messages through JNDI lookups. LogTape doesn't have any such mechanism:

1. Structured logging in LogTape simply organizes data in a structured format rather than plain text. This is a widely adopted industry practice that makes logs more searchable and analyzable.

2. Lazy evaluation in LogTape doesn't execute arbitrary code or user input. It only calls developer-defined functions when a particular log level is enabled—it's purely a performance optimization to avoid unnecessary calculations for disabled log levels.

There's no mechanism in LogTape that would allow arbitrary code execution through log messages as was the case with Log4Shell.

On project maturity

The maintainer could disappear tomorrow, and you will end up with hundreds of call sites to a library that is no longer maintained.

While LogTape is indeed relatively new (released in April 2024), it has been designed with careful consideration. The codebase is intentionally small with zero dependencies, making it easier to audit and maintain. I'm committed to maintaining the project, and its modular design enables others to contribute or fork if needed.

---

Thank you for the discussion, and I'm happy to address any other questions or concerns about LogTape.

[iuioiua]

Deno's gone all in on OpenTelemetry. I suggest we deprecate @std/log in favour of OpenTelemetry and any other high-quality third party logging frameworks like LogTape, then remove it. Reminder that this doesn't break existing codebases that use @std/log.

[iuioiua]

@kt3k WDYT?

[cristian-spiescu]

I have a project running an older deno. I planned to upgrade it. But if I'll do, std/log won't be there any more. Is it OK if I have a new deno, but I still reference an older std/deno?

[xseman]

Is there an idea to release @std/log independently from @std? Would be sad to see it gone without continuity..

[kt3k]

@cristian-spiescu

I have a project running an older deno. I planned to upgrade it. But if I'll do, std/log won't be there any more. Is it OK if I have a new deno, but I still reference an older std/deno?

While we removed it from github repo, it continues existing in JSR and deno.land. You can keep using either of them.

@xseman

Is there an idea to release @std/log independently from @std? Would be sad to see it gone without continuity..

We don’t have a plan to publish it anywhere else. If you feel strongly about it, I’d recommend forking it as a third-party library.