Colour support on TravisCI

[Berkmann18]

I'm currently working on a package where I'm planning on switching to chalk and up to now TravisCI didn't have any problems with colours on the console (using colors) but after pushing some code with passing tests (on the chalk-based codebase), Travis seems to disable colours which make all the tests fail.

I've understood from this comment that TravisCI seems to non-determistically change supports-color but I'm unsure if there's a fix for that or if I have to manually enable it using chalk.enable = true or even set the chalk.level to something other than 0 (which is what I get on the TravisCI log).

EDIT: if (!chalk.enabled) chalk.enabled = true; doesn't help.

[nazrhyn]

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"
}

[Berkmann18]

@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.

[Qix-]

@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.

[nazrhyn]

@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: https://github.com/chalk/chalk/issues/234

Are you saying that's been fixed?

[Qix-]

@nazrhyn I saw your post; please see https://github.com/chalk/chalk/issues/234#issuecomment-440326870. It was never 'broken', just not obvious.

[nazrhyn]

@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? :thinking:

[Qix-]

@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.

[nazrhyn]

@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.

[nazrhyn]

@Berkmann18 So, the conclusion was in https://github.com/chalk/chalk/issues/234#issuecomment-405040273 (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.

[Berkmann18]

@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.

[Berkmann18]

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

[Qix-]

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

[Berkmann18]

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

[nazrhyn]

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?

[Berkmann18]

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

[Qix-]

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.

[nazrhyn]

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.

[Berkmann18]

@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?

[Qix-]

@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.

[Qix-]

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

[Berkmann18]

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.

[Qix-]

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

[Berkmann18]

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

[sindresorhus]

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

[sindresorhus]

Closing as TravisCI is no longer relevant.