Comments (25)
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:
- no color support
- 16 colors (32 total, with bright and dark)
- 256 colors
- 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.
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.
Related Issues (20)
- Implementing the NO_COLOR environment variable standard HOT 1
- support for NO_COLOR env var HOT 5
- False-negative on GitHub Actions HOT 22
- What is wrong with the native `writeStream.getColorDepth`? HOT 3
- How to force using colors from browser? HOT 1
- Broken build with rollup for node due to global "navigator" HOT 6
- supportsColor() should recheck process.env.FORCE_COLOR HOT 2
- Change to ESM causes backwards compatibility issues HOT 3
- Implement `NO_COLOR` informal specification HOT 1
- "Can't resolve node:tty" when using nextjs and yarn 3 HOT 1
- No way to force color in browser HOT 9
- `navigator.userAgentData` HOT 1
- Support importing via deno HOT 3
- GitHub Action support truecolor HOT 1
- SyntaxError in index.js HOT 2
- My terminal emulator (mobaxterm) supports truecolor, but supports-color doesn't detect it HOT 4
- Package published without README HOT 1
- Claimed support for Node.js v12 missing HOT 10
- process is not defined in supports-colors.js HOT 1
- `FORCE_COLOR` testcases failing (fixed 2) HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from supports-color.