Improve the detections #98

I'm gonna re-title this issue to be about improving the detection logic.

@issuehunt has funded $60.00 to this issue.

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

@sindresorhus idk about you but I'd personally love to retire the argv sniffing we do in this package.

@Qix- I don't think we should retire it, it's useful for the common case. Instead, we should also expose the detections without the flag logic, per https://github.com/chalk/supports-color/issues/40#issuecomment-510786871.

@sindresorhus It causes some annoyance when dealing with argument parsing, and I personally believe it's out of scope for the project. This module is to detect color support in the terminal with a potential environment variable override. Sniffing argv is pretty sacred IMO, and while I understand that might break some applications that rely on this it wouldn't be hard to migrate whatsoever.

It might make sense to support an .setGlobalSupportLevel() method to help polyfilling the old support.

But as it stands, I think it's an artifact of feature creep since it's very intensely opinionated and non-specified. We're essentially dictating how the CLI of a program should look or behave, especially without a lot of users even knowing it.

Not that we have any real metrics to support it, but I hypothesize that the vast majority of users that want to override the color support level use environment variables instead of command line flags.

Just my $0.02. I think I left a comment elsewhere (I can't find it now) about how this would look programmatically with chalk, since it's our no.1 consumer.

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 :)