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 #144 (comment) #1555 (comment). 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: pinojs/pino#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 denoland/deno#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.