-
Notifications
You must be signed in to change notification settings - Fork 942
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Compatibility layer #644
Comments
I'm not sure I understand -- I thought the goal of #582 was to introduce a minor version with a default format that'd be backward-compatible with older versions (identical format, show / hide date and color if output is a tty, support env vars like Did I miss something? What would a "compatibility layer" have to patch, and if the newest version is installed, doesn't that means there would be no older version to patch? |
The old versions will still have the old version (versions 0.x, 1.x, 2.x and 3.x). Either we back-port or we monkeypatch, really. So the problem is that old libraries that have a range of e.g. Luckily, it looks like the environment variables and general API have remained pretty much the same since 0.x, which means patching is not a bad route to go. The problem with backporting is that it runs the risk of breaking a lot of people. To be clear, the problem is this: versions 0.x, 1.x, 2.x and 3.x would not know to look for the |
Since the patching or backporting is really risky, perhaps there's a third way by using There are a few problems with this approach:
It's a rock and a hard place, really. I do like the idea of making @TooTallNate @sindresorhus your thoughts would be really appreciated here. Any ideas on the best way to tackle this problem? |
I don't think it's feasible to backport to all old versions. Some packages might even have the dependency locked to a specific 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 |
Well if we monkey patch then maybe we can funnel into a log handler, which can then be plugged into optionally by Best of both worlds. |
Something else to consider: #425 - Just want to make sure it's on the radar. |
In terms of |
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 sincedebug
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?The text was updated successfully, but these errors were encountered: