thelindat
commented
1 year ago Not going to work on this at the moment since it would end up delaying v3.0. If/when I can be bothered I'll have it as a new module so lib.logger can sit there for compatibility. Was actually something I looked into for ox_core around October but ehh - benefit to time spent is out of whack considering most people want to use Discord for their logs.
Summary
This issue is a suggestion for expanding the current logging module to include a fully-fledged feature set similar to the capabilities of popular logging libraries present in other popular ecosystems, such as Go or NPM, while still retaining the current transport ability to services such as DataDog or Grafana's log management service.
Note: Implementation of an expanded logging module as described below has a high likelihood of breaking backward compatibility for the current log schema being transported to supported log aggregation & management platforms
Featureset of an Enhanced Logging Module
For the implementation of an enhanced logging module, I would personally like to see the following:
Log Level Capabilities and Generic Logging
The current logger module implementation is mainly targeted at a specific use case (as can be inferred by the signature). Therefore, it isn't ideal for serving as a consolidated log controller for generic logs across a server's entire resource catalog.
When logging in to other development contexts, a log entry is often associated with a certain level and severity. For example, some typical log levels are "trace," "debug," "info," "warning," and "error." Additionally, in many libraries, a log level tied to an entry will often result in "pretty" formatting, such as color, in the console output.
These capabilities would also allow for introducing a multitude of additional possible configuration options to control behavior, for example. For example, a configuration option for a global log level could be hypothetically configured to control whether a log is written out to the terminal or silent.
Local Log Level Files and Log Rotating
Another excellent addition would be local log-saving capabilities. Log rotation abilities for large servers with many log entries could also be an interesting use case to target. Still, it may not be a feature worth targeting in the initial implementation.
Existing Logging Libraries with Features of Interest
Below I've included some popular logging libraries with features similar to the ones proposed by this issue.
Winston (NPM) Pino (NPM) Logrus (Go)
Conclusion
If an implementation of the described capabilities above interests the team, I would be happy to flesh out this issue further to include specifics regarding implementation details, behavioral specifics, and a more formal proposal for changes to the public API.