Repository navigation
Use the level function on the console API instead of strictly console.log #405
Description
Activity
Hi @kevinlacotaco ,
Yes. Currently, the SDK only uses
console.logbut 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
Loggerinstance. 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
_generateLogMessageis what is passed toconsole.log(), so you will seeundefinedvalues in the console too.For more details, logger/index.ts contains the
Loggerclass thatfactory.settings.logis 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.
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.
Hi @faizanu94. Good timing :)
We’re currently working on supporting custom loggers in our SDKs, and a new version of the Node.js SDK (
@splitsoftware/splitio) will be released next week.We don't want to change the console method used by default, since the JavaScript Commons source code is shared with other libraries (e.g. our React Native SDK), where using
console.errorcan be more intrusive when debugging mobile apps.However, starting with version 11.7.0 of
@splitsoftware/splitio, you’ll be able to provide a custom logger. For example:const factory = SplitFactory({ ... debug: true, logger: console }
Any provided logger must implement the SplitIO.Logger interface, like the global
consoleobject:interface Logger { debug(message: string): any; info(message: string): any; warn(message: string): any; error(message: string): any; }
For example, the default logger (with the current behaviour) looks like this:
const DEFAULT_LOGGER: SplitIO.Logger = { debug(msg) { console.log('[DEBUG] ' + msg); }, info(msg) { console.log('[INFO] ' + msg); }, warn(msg) { console.log('[WARN] ' + msg); }, error(msg) { console.log('[ERROR] ' + msg); } };
Thanks for the context @EmilianoSanchez - yes it makes sense about React Native and other SDKs.
I opened this PR mainly to unblock Datadog/browser-log users who rely on console methods for log forwarding.
Glad to hear custom logger is landing in v11.7.0 - I’ve closed my PR in favor of #425
Reacted by Emiliano SanchezHi @kevinlacotaco , @faizanu94
We've released a new version of our SDKs that includes the custom logger feature:
@splitsoftware/splitio>= 11.7.0 (Docs for Node.js)@splitsoftware/splitio-browserjs>= 1.5.0@splitsoftware/splitio-react-native>= 1.4.0
Example:
import { SplitFactory } from '@splitsoftware/splitio' const factory = SplitFactory({ ... debug: true, // enable all log levels logger: console // will use `console.debug|info|warn|error` methods instead of the default `console.log` }
I'll close the issue, but feel free to reach out if you have more questions.
Using an alternative browser log aggregator (DataDog browser-logs) we forward
warn/erroronly.Internally this package currently just uses
console.logwith 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.