Improve the detections

getColorDepth() was added in Node.js 9.9.0 and hasColors() and FORCE_COLOR=0|1|2|3 to Node.js 11.13.0. They are directly based on this module’s code.

supports-color brings extra features:

• supports CLI flag [--no]-color[s]
• supports browsers (which always default to “no colors”)
• hasColors() is undefined if stream.isTTY is not true, i.e. one needs to do stream.hasColors !== undefined && stream.hasColors()

On the other hand, getColorDepth() and hasColors():

• are in core Node.js
• supports more fine grained color detection logic. See the current code. They basically handle much more environment variables cases.

My question is: wouldn’t it make sense to do the following?

• export ponyfills of getColorDepth() and hasColors(). Basically, just copy/pasting the code. If the Node.js running version supports those functions, they can be directly used. Those ponyfills could be removed in the future once Node.js supported versions are upgraded.
• use those methods instead of the current detection logic.

---

IssueHunt Summary

Backers (Total: $60.00)

• issuehunt ($60.00)

Become a backer now!

Or submit a pull request to get the deposits!

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

---

IssueHunt has been backed by the following sponsors. Become a sponsor

[Qix-]

So I’ve since updated my views after looking at some of the PRs that went into Node’s color depth “feature”.

The amount of thought and discussion that went into it was next to nothing. Their use of the term “depth” isn’t even correct.

Some of the PRs were merged even after someone objected with “perhaps we should standardize this”. None of us at chalk were pinged - which I realize isn’t a requirement, but a lot of the concerns and discussions that would have benefitted the implementation are those we’ve had time and time again with users, developers and terminal emulator implementors alike over almost a decade.

That color depth method will probably break your code at some point, given how little thought and effort went into it. I’d highly recommend against using it.

---

While this sounds like something we should support, there’s too high of a chance this would cause headache in the future. It’s really hard to remove a check gracefully, without breaking a lot of people, than it is to add it - and this would definitely cause problems later on.

Thank you for the suggestion, it was a very good one but alas just didn’t pan out 😃

[sindresorhus]

It’s awesome that it’s now in Node.js. The problem is that the detection will be ever changing, so I don’t think we’ll ever be able to actually use the native methods as we favor stability over all Node.js versions we support. Imagine if the detection in Node.js core changes between each major version and we support 3 major versions in Chalk. That will create a bad experience for the user.

Another reason I don’t want to depend on the Node.js logic is that we can move faster while Node.js is locked into their major version schedule for breaking changes.

I think the best way forward is to just improve our detection with inspiration from the Node.js logic.

---

They basically handle much more environment variables cases.

That’s not always a good thing. The more fine-grained cases you handle, the more assumption there are that could be broken at any time.