[Proposal] Deprecate RxPlayer `LogLevel` getter/setter in profit of the "rx-player/logger" dependency

[Paul Berberian]

The RxPlayer class defines the LogLevel static property - internally through getter and setter functions - allowing an application to display RxPlayer logs for easier debugging.

However, since the v3.5.0 (2018-07-03), it is also possible to import the RxPlayer's logger instance through the "rx-player/logger" path (even though this is very poorly documented, if at all).

We did this because some of RxPlayer's external tools (the VideoThumbnailsLoader, the mediaCapabilitiesProber and surely others), rely on internal code which call the same logger than the one used when in the RxPlayer class context.
In that condition, it appeared weird to us that the only way to update the logging level would be through a static property of the RxPlayer:

• updating that level would mean importing the RxPlayer class, even if only the tool was imported (which does not need to import the whole RxPlayer class) - e.g. just to parse BIF thumbnails or to display external text tracks on top of the video
• Even when both were imported in that application, it would be unclear that updating the log level of one would also update the log level of the others

So that's why we decided to create a rx-player/logger path, which would expose the logger on which all those tools, and the RxPlayer class, rely, explicitely and "stand-alone-ly"!

---

The current situation (having both the path and static properties) does no for the moment cause any problem.
However, I plan to add a new feature to the exposed logger that I hesitate to replicate as a RxPlayer static property: the ability to ask for a timestamp to be included before each log.

Even if it might only be added though a second optional property of the Logger instance, something like logger.setLevel("DEBUG", { shouldIncludeTimeStamp: true }) exposing this feature as a RxPlayer static property would mean adding a new static property - let's say LogsIncludeTimeStamp. To me, this seems highly unelegant and could add to the confusion of which property is - or is not - shared.

This feature could also just be added to the Logger instance and not as RxPlayer static property but this could also be confusing to have - and to document - two set of APIs interacting with each other with different levels of features: one easier to use with less features (the RxPlayer static property) and the other needing another import but with more features.

---

That's why I created this proposal: should we deprecate the RxPlayer class's LogLevel static property (a path to a removal in the future v4.0.0) in profit of the rx-player/logger path and only add new features to the latter?

I'm still unsure as this might mean a minor inconvenience for application developers - when the goal is to be exactly the opposite of that!

Thoughts?