You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Use the level function on the console API instead of strictly console.log #405
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.
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:
constfactory=SplitFactory(SDK_CONFIGURATION);// @ts-expect-error `log` is not part of the public TypeScript Definitionsfactory.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.
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.
It updates the Logger to use console.debug, console.info, console.warn and console.error instead of always console.log so tools like Datadog can correctly capture logs by level.
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.error can 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:
import{SplitFactory}from'@splitsoftware/splitio'constfactory=SplitFactory({
...
debug: true,// enable all log levelslogger: 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.
Activity
EmilianoSanchez commentedon May 16, 2025
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: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.
kevinlacotaco commentedon May 16, 2025
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.
faizanu94 commentedon Oct 3, 2025
Hi all, I’ve opened PR #433 to address this.
It updates the Logger to use
console.debug, console.info, console.warn and console.errorinstead of alwaysconsole.logso tools like Datadog can correctly capture logs by level.Would love your feedback!
EmilianoSanchez commentedon Oct 3, 2025
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:Any provided logger must implement the SplitIO.Logger interface, like the global
consoleobject:For example, the default logger (with the current behaviour) looks like this:
faizanu94 commentedon Oct 3, 2025
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
EmilianoSanchez commentedon Oct 8, 2025
Hi @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.0Example:
I'll close the issue, but feel free to reach out if you have more questions.