turbo
turbo copied to clipboard
vercel
Support colored output from original CLI
Describe the feature you'd like to request
Show original CLI colors in the output.
Describe the solution you'd like
I would like to be able to have a --colors flag when running turbo to enable colors of the CLI output, including the output from the sub packages/apps. turbo would likely set the environment variable FORCE_COLOR=1 before running commands.
Describe alternatives you've considered
Manually setting the monorepo's environment variable to FORCE_COLOR=1. This enables color when packages, like Next.js, use the npm package chalk
Start here: https://github.com/vercel/turborepo/blob/155c5c3451f1e5ef26034fc9eeb99b40bb98b838/cli/internal/run/run.go#L716
and around here is where to set FORCE_COLOR: https://github.com/vercel/turborepo/blob/155c5c3451f1e5ef26034fc9eeb99b40bb98b838/cli/internal/run/run.go#L487
I had a little time to try implementing this and found that the FORCE_COLOR environment variable needs to be set in the working directory where the command is executed (for example docs). Setting it after line 487 doesn't correctly force the color.
I'll work on this more tomorrow. Let me know if you have any ideas. Go is a new language to me.
If you're using node, you can set FORCE_COLOR=1 in your environment variables. The PR hasn't been reviewed.
@charkour Yea that's what I'm currently using, but it seems like quite a dirty solution, For example, if you have 10 packages with each of them having roughly ~4 commands
This would mean that you need to make at least 40 changes to enable colors.
I think it would be much better to use --colors, or considering the comment in your PR, the flag could be something like --node-colors instead, and eventually a unified --colors flag depending on the decisions. but yea the feature in your PR would be most welcoming. That would avoid having to set the FORCE_COLOR=1 in ~40 different places 😅
@charkour Has this been implemented yet?
Seems like a neat thing to have.
Hey @narutosstudent, I don't believe this has been implemented yet. My original PR was closed because I had incorrectly made this assumption about node environments being the only use case for turborepo.
For a workaround, I'd recommend using FORCE_COLOR=1 in your environment variables if you are using a node environment.
I'm having problems in my local terminal (i'm using tilix on linux) to show colors automatically, i think the TTY detection is not working as it should. Other utils are showing colors without any problem.
@jaredpalmer could be a problem with this line ?
https://github.com/sebaplaza/turborepo/blob/main/cli/internal/ui/ui.go#L17-L18
Edit: I tested the go-isatty output and the tty is being detected, the problem is that isTTY is not being used as a method to activate colors.
@charkour Yea that's what I'm currently using, but it seems like quite a dirty solution, For example, if you have 10 packages with each of them having roughly ~4 commands
I think it would be much better to use
--colors, or considering the comment in your PR, the flag could be something like--node-colorsinstead, and eventually a unified--colorsflag depending on the decisions. but yea the feature in your PR would be most welcoming. That would avoid having to set theFORCE_COLOR=1in ~40 different places 😅
FYI, you don't have to put FORCE_COLOR into every package, only before the turbo run command in your top level package.json. For example, this worked for me to get colors working with vitest:
{
"scripts": {
"test": "FORCE_COLOR=1 turbo run test"
},
}
And the actual package.json for the package only includes
{
"scripts": {
"test": "vitest"
},
}
just another piece of info here that this also seems to apply to running turbo itself which is not a great look.
aka: turbo typecheck:all (which is "typecheck:all": "turbo run typecheck --continue" in root package.json) works but is completely white which makes it nearly impossible to discern the output from different packages.
no spinners, colors, and other terminal progress animation/indicators.
I wanted to cite this from the closed-as-duplicate #2251 issue. Can we change the title of this to Support output from original CLI (colors, spinner, etc)? I occasionally search for spinner and hope to more quickly find this one to check on progress. (I have also subscribed this time 😉.)
FORCE_COLOR=1 does not seem to help with spinners or other animation.
Just want to voice my support for adding this. It is extremely important for dev ergonomics and accessibility.
Just want to voice my support for adding this. It is extremely important for dev ergonomics and accessibility.
@finnatsea just add FORCE_COLOR=1 as an env variable and you'll have that! :)
FORCE_COLOR=1 Is not working for me, and based on the responses here since the first mention of that solution, it is also not working for others. My guess if folks recommending it are not clear on what is being requested. This request is for the original cli output from the task to maintain it's colors. This usually will mean the child process' need to be run in a TTY, and my educated guess (I read some of the code here) is that this env var does nothing to effect how the process is spawned. So unless whatever tools are run in the task process also respect FORCE_COLOR then they will not think they should display colors.
If this was a JS package, we could use node-pty and even the most rudimentary tools would likely follow suite and display colors. Since this is not JS, I have no idea if there are any good libraries for this. But I would like to say that until this feature is added, the UX of running turbo in anything but CI is significantly worse than it could be.
An example:
https://github.com/tapjs/tap-mocha-reporter/blob/f4b1acea21f723a68ea5be2ec321a1a0412c0cea/lib/reporters/base.js#L5
This package for parsing tap output uses TAP_COLORS as it's override, but will respect if the stdin/out is TTY. If I manually set this in my package.json script, turbo will maintain the colors with or without FORCE_COLOR being set. But that means that EVERY single consumer needs to know what options are available in each tool to force colors, and it means the normal detection libraries need to do is overridden. This can cause issues in CI systems which don't understand colors (jenkins used to be like this).
Why isn't this the default? I know that some maintainers consider this a low on the list nice-to-have, but I could not disagree more. This is so pronounced that nx even have a section about how much this sucks and is a reason to choose nx instead...
I am sure there is some hidden complexity around this, but thats not a reason to abandon this for almost 2 years.
If it is required and some maintainer is willing, I will gladly 1:1 to understand how to implement it, and make a PR
Not sure it seems a very complex explanation but it is working for me:
@ZeldOcarina This is because whatever is running in your task is doing one of two things:
- ignoring that it is not a
TTYand ouputing ansi color escape codes anyway (which is generally not considered good) - respecting
FORCE_COLORto turn them on. which is fine, but not all tools do this.
What my comment above was about is having turbo trick the task process into thinking it is running in a TTY shell which would set the correct defaults for almost all tools in the node.js ecosystem.
After waiting over a year, we're moving to nx almost solely because of this. We even overlooked the failing daemon issues on Windows (ended up just disabling it). But eventually it was determined that colorized lint/format/test/build/* output is too critical for development and none of the workarounds attempted/suggested were satisfactory.
@billyzkid In case this update helps you, I think I was able to get colors out of all the tools I was using by wrapping the call to turbo in a pty via node-pty. I think one of the reasons this is confusing folks is that there are many layers at work. I know nothing of your setup, but I think that no one in this thread has (including myself) posted a reduced test case for where turbo specifically is breaking the colors. And seeing as I was able to get colors in my tool which parses the turbo log output and transforms it into a web ui with colors in the logs, I am pretty sure at this point turbo is not the cause but is only making the reason harder to debug.
Using concurrently, colors from concurrently won't show in terminal when starting from turbo
@Adrien5902 concurrently is almost certainly doing this wrong, but did you try passing --no-no-color? Yargs boolean args should not include no- because it will do it itself. I took a quick look at what it is doing with with that option and under the hood it passes FORCE_COLOR to the tools, but that env var is not universal, hence the problem with tools like this not using a PTY.
Either way, I don't think your issue with with turbo.
@wesleytodd thanks for answering, you must be right, I don't know why vite has colors while concurrently doesn't but it does not matter the issue is probably with concurrently. I resumed working on this old project which used concurrently and I moved to a monorepo to have server side and client side split. But it'll be even better if I split electron and vite in two different packages anyway. So I won't have the need for concurrently anymore.
An update for those following this issue: We're aiming to land this feature in Turborepo 1.12!
