Improve the detections
See original GitHub issuegetColorDepth()
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()
isundefined
ifstream.isTTY
is nottrue
, i.e. one needs to dostream.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()
andhasColors()
. 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
Issue Analytics
- State:
- Created 4 years ago
- Comments:7 (6 by maintainers)
Top Results From Across the Web
Five Ways to Enhance Your Problem Detection Skills
Five ways to enhance your problem detection skills. How good are you at noticing problems, risks and hazards in your life and work?...
Read more >Improve the performance of your Object Detection model
There are different solutions by which you can improve the performance of your object detection model like improving your data set with the...
Read more >Improve the performance of your object detection model
We have seen how to build a custom object detector using Faster RCNN with PyTorch. That model performed pretty decently with the IOU...
Read more >Improved detection of small objects in road network sequences
In this work, we propose a new procedure for detecting small-scale objects by applying super-resolution processes based on detections performed ...
Read more >3 Steps to Improve Network Security Threat Detection - Cybriant
Network security threats are continuously growing in quantity and severity. Here are three easy steps to improve your network security threat detection.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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 😃
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.
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.