Colour support on TravisCI about supports-color HOT 25 CLOSED

I noticed the reference to my issue and thought I'd chime in: until that issue is resolved, once chalk has detected color is not supported, it's not possible to turn it back on programmatically.

That said, as I mentioned elsewhere, if you force colors on via the various methods detected starting here:
https://github.com/chalk/supports-color/blob/master/index.js#L12

It should work just fine.

For example, to make sure that color codes are printed to syslog (while this is still an issue), we just added the --color parameter to the start script for the node processes where we use chalk. Something like this:

{
    "start": "node server.js --color"
}

from supports-color.

@nazrhyn Didn't catch it, sorry. No need to be grouchy. Sindre has hundreds of projects he's working on and I have a full time job and have been in the midst of an intercontinental relocation.

from supports-color.

@Qix- Certainly wasn't trying to sound grouchy, rather just trying to keep tabs on the issue I submitted and understand how to use chalk. I'll move any further discussion about the issue over to it.

from supports-color.

@nazrhyn I've manually set both with:

chalk.enabled = true;
chalk.level = 2;

Which still makes all the test pass (locally); however, TravisCI still fail and I noticed it can only go as far as chalk.level = 1.
The problem is that by setting my code to chalk.level = 1 is that it breaks some test cases and limits me to fewer colours which defeat the purpose of the switch to chalk.

from supports-color.

@Berkmann18 What you're describing isn't chalk's fault. If some colors work and some do not, that's something that Travis needs to fix and has nothing to do with Chalk.

There are four levels of support that we can detect:

0. no color support
1. 16 colors (32 total, with bright and dark)
2. 256 colors
3. 16 million colors ("truecolor")

If Travis can support more colors, then great - a PR should be made against supports-color. Otherwise, I believe things are functioning correctly.

WRT your second snippet, those are cases where higher levels of support were not previously detected. Keep in mind the order of supports-color matters entirely.

from supports-color.

I've emailed them again as I've received no response other than the above.

from supports-color.

@Berkmann18 Try posting here instead: https://travis-ci.community/

from supports-color.

@nazrhyn I managed to get more tests to pass by using jest --color instead of jest but the test passing rate differs on TravisCI compared to when I run the test suites locally.
Here's the Travis test for reference.

Here's where TravisCI is messing up:

chalk.keyword('orange')
chalk.magenta

And that's pretty much it for now.

from supports-color.

@nazrhyn

it's not possible to turn [chalk] back on programmatically.

If you're referring to code, that's objectively untrue.

Travis has been a continual PITA. It doesn't surprise me it broke again. Please open a ticket at supports-color, though - that's the main repository where we can investigate.

from supports-color.

@Qix- You missed part of my quote:

[...] once chalk has detected color is not supported, it's not possible to turn it back on programmatically.

That's the entire basis of the issue I submitted a while back: chalk/chalk#234

Are you saying that's been fixed?

from supports-color.

@nazrhyn I saw your post; please see chalk/chalk#234 (comment). It was never 'broken', just not obvious.

from supports-color.

@nazrhyn I saw your post; please see #234 (comment). It was never 'broken', just not obvious.

So, you guys asked me to create a failing unit test for something that was functioning as designed? 🤔

from supports-color.

@Berkmann18 So, the conclusion was in chalk/chalk#234 (comment) (which I was missing, somehow). Due evolution over time, it looks like both of the following are required to programmatically enable chalk:

• level > 0
• enabled === true

It seems like chalk/chalk#234 should probably be closed.

from supports-color.

@nazrhyn @Qix- Any ideas about a workaround/solution for that?

from supports-color.

Only having 16 colors on Travis is not our problem, it's Travis's. Please open an issue there.

from supports-color.

@Qix- Okay, I've emailed them (since they don't accept issues on their repo) and will post updates here.

from supports-color.

I guess this still seems strange to me. Isn't applying color codes just a string replacement, at the lowest level? Doesn't it just boil down to: do we perform the substitution or do we not perform it?

from supports-color.

@nazrhyn In my understanding, it is essentially just a string replacement.

from supports-color.

Isn't applying color codes just a string replacement, at the lowest level?

Not quite sure what you mean, but it's more than "string replacement". We have to keep track of open and close codes, similar to HTML. Further, the codes are based on a several-decade-old standard that was birthed out of archaic terminals (before even the internet was around).

The codes don't do anything special - the actual color display must be implemented correctly and fully by whatever displays a program's output.

from supports-color.

I'm certainly not trying to be reductive of the technical hurdles required to produce the result. However, these two calls...

chalk.green('hello');
// or
chalk`{green hello}`;

...become something like...

'\u001b[32mhello\u001b[39m'

One string has been transformed into the other after the intention has been interpreted. The reason I'm making this distinction is because it seems that, for a hypothetical coloring library that doesn't have any capability detection smarts, there should be no reason why it wouldn't always produce the same output.

So, given that chalk does have that, it has to be something about the color detection that causes the difference, right? Since the original issue is that tests which attempt to verify colored output are failing (unless I'm misunderstanding the original issue).

However, maybe there's some big thing I'm missing here? Please correct me if I'm missing some other complexity in how chalk works that makes what I'm saying complete nonsense.

from supports-color.

@nazrhyn There's perhaps a way for the colour detection to map unsupported colours to others (say if bright blue isn't supported on X then it would use the cyan colour) although I haven't looked at the support-color package to see how it worked other than how chalk and colors work.
Then obviously the recipient terminal (read the terminal where the coloured output is to be displayed) would play a role in how colours and obviously how many colours will be displayed.

Regarding my issues, some colours are being displayed fine but some aren't (it appears like it was uncoloured text instead).

I'm more than happy to help to improve this package or even this sort of technology (colour detection and display like how chalk and colors to an extent).

EDIT: Just had a look at this and noticed that it was forcing level 1 (or 0 if forceColor = false) on CIs as well as in this snippet so I'm wondering if it could be improved or if the targetted environments couldn't just get a broader set of colours?

from supports-color.

I'm also moving this issue to supports-color as it belongs there, not here.

from supports-color.

Hi there Max,

Thanks for getting in touch with us about this, and I've escalated this as a feature request to our Product team. Unfortunately I can't say when or if this will be implemented.

from supports-color.

Yeah I'm a little surprised they don't support more colors. Most libs that handle this for HTML handle more than 16.

from supports-color.

Closing as TravisCI is no longer relevant.

from supports-color.