Use the level function on the console API instead of strictly `console.log`

[kevinlacotaco]

Using an alternative browser log aggregator (DataDog browser-logs) we forward warn/error only.

Internally this package currently just uses console.log with a formatted message that DataDog currently ignores since it is not greater than warn. If the console methods are used we would get proper forwarding for the levels which we have configured.

[EmilianoSanchez]

Hi @kevinlacotaco ,

Yes. Currently, the SDK only uses console.log but we want to support custom loggers eventually by providing an extra configuration option to the SDK (something similar to what other 3rd-party libs do, for example, http-proxy-middleware).

In the meantime, you can try to monkey-patch the internal Logger instance. For example:

const factory = SplitFactory(SDK_CONFIGURATION);

// @ts-expect-error `log` is not part of the public TypeScript Definitions
factory.settings.log._generateLogMessage = (level, message) => {
  switch (level) {
    case 'DEBUG':
      console.debug(message);
      break;
    case 'INFO':
      console.info(message);
      break;
    case 'WARN':
      console.warn(message);
      break;
    case 'ERROR':
      console.error(message);
      break;
  }
};

But this has an inconvenience: the result of _generateLogMessage is what is passed to console.log(), so you will see undefined values in the console too.

For more details, logger/index.ts contains the Logger class that factory.settings.log is an instance of.

We can keep the GH issue open, and once we provide a custom logger option, I can let you know and close it.

[kevinlacotaco]

Thanks! Yeah, we are using yarn so I just applied a yarn patch to our current split package.

That gets the console method from the level passed in and if it matches a valid console method to use it otherwise just log. It'll work for now. We started getting the logs and are able to address the errors/warns since our infos are otherwise ignored. It fits the bill for the time being.