[RFC] Compatibility layer

One problem we’re going to be facing, now that I’m thinking about it:

We will be introducing the ability to specify a custom output format with #582.

This new output support (the env-var support) won’t be available for older versions, which means debug will now be showing different output formats for old versions of the library, which is a problem since debug is almost as old as node.js IIRC.

That means users that set DEBUG_FORMAT will see inconsistent output formats for code that is any older than the new major version release.

---

Should there be a compatibility layer introduced in the newest version that sniffs out older versions of debug and patches them up, being version-aware in terms of the API?

[sindresorhus]

I don’t think it’s feasible to backport to all old versions. Some packages might even have the dependency locked to a specific debug version too, so it would not work then. And if you can’t reliably do for all situations, is there really any point.

This would be a good time to come up with some way to monkeypatch that would let you introduce other flags and changes in the future too. Maybe by making all the debug() instances minimal with a well defined transport that will never change and have the core as a singleton that mediates those minimal instances, where it uses the newest registered core. Since the latest version always becomes the singleton, it knows how to handle all older versions.

[Qix-]

Well if we monkey patch then maybe we can funnel into a log handler, which can then be plugged into optionally by node -r. Then we could have a json log consumer and not have to deal with those formatters (cc @chagris).

Best of both worlds.