discussion: logging about framework HOT 12 CLOSED

I'm already happy there is not "wtf" logging level because that one was so stupid lmfao

from framework.

How about allowing users to inject their own logger that extends an abstract class, and having the default implementation use console.log?

from framework.

How about allowing users to inject their own logger that extends an abstract class, and having the default implementation use console.log?

That really would be the best option. Just a generic abstract class people can either implement or default. Reminds me a lot of most C# libraries tbh.

from framework.

Would like to see that, I support it.

from framework.

Sounds good, although the built-in logger will probably have opt-in logging, like all other libraries do.

const enum LogLevel {
  Trace = 10,
  Debug = 20,
  Info = 30,
  Warn = 40,
  Error = 50,
  Fatal = 60
}

interface ILogger {
  trace(...values: readonly unknown[]): void;
  debug(...values: readonly unknown[]): void;
  info(...values: readonly unknown[]): void;
  warn(...values: readonly unknown[]): void;
  error(...values: readonly unknown[]): void;
  fatal(...values: readonly unknown[]): void;
  write(level: LogLevel, ...values: readonly unknown[]): void;
}

ILogger#write serves so you can filter out emits (all other methods emit to it), i.e:

class Logger implements ILogger {
  public minimum: LogLevel;

  // Other methods

  public write(level: LogLevel, ...values: readonly unknown[]): void {
    if (level < this.minimum) return;
    // Write to console
  }
}

I think this streamlines with many other logger implementations, what are your thoughts? The idea behind LogLevel taking steps of 10 each is so developers can augment it with new levels between existing ones, following TypeScript's requirement - we can augment enums as long as their values don't conflict.

I also took the names from StackOverflow and IBM.

Thoughts?

from framework.

Sounds good, although the built-in logger will probably have opt-in logging, like all other libraries do.

By this do you mean a plugin, client option, or a class from a package passed as the client option/static property on the class?

from framework.

Sounds good, although the built-in logger will probably have opt-in logging, like all other libraries do.

By this do you mean a plugin, client option, or a class from a package passed as the client option/static property on the class?

As in, the minimum will be set by default to a number higher than LogLevel.Fatal so nothing is logged, and this would be set with ClientOptions.Logger.Level. Keep in mind the default logger will simply do calls to Node.js's built-in console and will therefore not format arguments nor add colours - it's not the framework's responsibility, and would certainly make it opinionated to force a dependency (or more, given colours + timestamp) to format logs, as some people will most likely override this logger with something, say a Winston-based or a Klasa-based one.

Plugin can still set this.logger = new MyCustomLogger(); after initialization to override this behaviour completely.

from framework.

As in, the minimum will be set by default to a number higher than LogLevel.Fatal so nothing is logged, and this would be set with ClientOptions.Logger.Level.

I think some amount of error logging by default would be reasonable. Users can always disable it if they don't want it, and enabling some errors by default would help new users of the library.

from framework.

As in, the minimum will be set by default to a number higher than LogLevel.Fatal so nothing is logged, and this would be set with ClientOptions.Logger.Level.

I think some amount of error logging by default would be reasonable. Users can always disable it if they don't want it, and enabling some errors by default would help new users of the library.

In my opinion it should be that theres a @sapphire/logging package which exports the base of the logger class or well interface. Followed by Framework using it with plain console logs or colourette and then if the user wishes to overwrite that they can pass a new instance of their own logger following the design of the interface.

from framework.

As in, the minimum will be set by default to a number higher than LogLevel.Fatal so nothing is logged, and this would be set with ClientOptions.Logger.Level.

I think some amount of error logging by default would be reasonable. Users can always disable it if they don't want it, and enabling some errors by default would help new users of the library.

In my opinion it should be that theres a @sapphire/logging package which exports the base of the logger class or well interface. Followed by Framework using it with plain console logs or colourette and then if the user wishes to overwrite that they can pass a new instance of their own logger following the design of the interface.

That sounds like it'll work, but if there's nothing major to it, having it within the framework should be fine.

from framework.

As in, the minimum will be set by default to a number higher than LogLevel.Fatal so nothing is logged, and this would be set with ClientOptions.Logger.Level.

I think some amount of error logging by default would be reasonable. Users can always disable it if they don't want it, and enabling some errors by default would help new users of the library.

In my opinion it should be that theres a @sapphire/logging package which exports the base of the logger class or well interface. Followed by Framework using it with plain console logs or colourette and then if the user wishes to overwrite that they can pass a new instance of their own logger following the design of the interface.

That sounds like it'll work, but if there's nothing major to it, having it within the framework should be fine.

Seems a bit bloated to have the structure for it in the framework since then if someone wishes to just create a package with a logger they would need the whole framework as the dep oppose to just the structure dependency.

from framework.

As in, the minimum will be set by default to a number higher than LogLevel.Fatal so nothing is logged, and this would be set with ClientOptions.Logger.Level.

I think some amount of error logging by default would be reasonable. Users can always disable it if they don't want it, and enabling some errors by default would help new users of the library.

In my opinion it should be that theres a @sapphire/logging package which exports the base of the logger class or well interface. Followed by Framework using it with plain console logs or colourette and then if the user wishes to overwrite that they can pass a new instance of their own logger following the design of the interface.

That sounds like it'll work, but if there's nothing major to it, having it within the framework should be fine.

Seems a bit bloated to have the structure for it in the framework since then if someone wishes to just create a package with a logger they would need the whole framework as the dep oppose to just the structure dependency.

I mean if the purpose for their package is to work with sapphire, I don't see why they'd mind not having it as dependency.

from framework.