Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Colors are not preserved, code lines are not clickable #8429

Open
1 task done
MickL opened this issue Jun 11, 2024 · 7 comments
Open
1 task done

Colors are not preserved, code lines are not clickable #8429

MickL opened this issue Jun 11, 2024 · 7 comments
Labels
kind: bug Something isn't working owned-by: turborepo

Comments

@MickL
Copy link

MickL commented Jun 11, 2024

Verify canary release

  • I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

What package manager are you using / does the bug impact?

npm

What operating system are you using?

Mac

Which canary version will you have in your reproduction?

2.0.3

Describe the Bug

When I run "bun lint" normally I can click the line of code and it jumps into it (using Webstorm). Also the warning is yellow and an error would be red:

338527936-be1c9902-2466-43c3-bfd4-450aea7193da

If I run the same with Turbo (same with ui: "stream") I cant click the line and the color is lost aswell:

338528607-10c68e50-58e2-40cd-8aae-1ffe0b462627

Tested in iTerm and Webstorm

Apperently the colors have been fixed with #223 but maybe since the new UI has landed they are gone again?

Expected Behavior

To Reproduce

Additional context

No response

@MickL MickL added kind: bug Something isn't working needs: triage New issues get this label. Remove it after triage owned-by: turborepo labels Jun 11, 2024
@jraoult
Copy link

jraoult commented Jun 11, 2024

@MickL I've had the same issue with Webstorm. With turbo v1 --log-prefix=none was enough, but with v2 I also have to disable the tui.

So typically for me this allow Webstorm to parse the lines and make them "clickable":

TURBO_UI=0 turbo run lint --log-prefix=none

It is not ideal but it is very convenient in dev.

@jskrable
Copy link

@MickL I've had the same issue with Webstorm. With turbo v1 --log-prefix=none was enough, but with v2 I also have to disable the tui.

So typically for me this allow Webstorm to parse the lines and make them "clickable":

TURBO_UI=0 turbo run lint --log-prefix=none

It is not ideal but it is very convenient in dev.

I'm seeing this issue in Warp as well after moving to turbo v2.

chris-olszewski added a commit that referenced this issue Jun 13, 2024
### Description

Partially addresses #8429

`chalk` the widely used library doesn't just factor in if stdout/stderr
are TTY for emitting color. In [heavily
relies](https://github.com/chalk/chalk/blob/386909ee0bfe4346d04e3eeba712f0db597c038d/source/vendor/supports-color/index.js#L60)
on environment variables for deciding what level of color to output.

In strict mode many of these env vars are stripped leaving us with
[color level
0](https://github.com/chalk/chalk/blob/386909ee0bfe4346d04e3eeba712f0db597c038d/source/vendor/supports-color/index.js#L94)
aka disabled.

`TERM`/`COLORTERM`/`TERM_PROGRAM` should cover the bases for most
terminals looking at the `chalk` source.

### Testing Instructions

Eslint should now have produce color even in env strict mode:
<img width="1150" alt="Screenshot 2024-06-12 at 4 32 11 PM"
src="https://github.com/vercel/turbo/assets/4131117/e3e1a0b7-690c-4997-9b41-5d91bb7cba0d">
@natacharome
Copy link

TURBO_UI=0 

Works well for me when lauching build command ! Thanks for the tip

@chris-olszewski
Copy link
Member

Can people experiencing this try out 2.0.4-canary.4? chalk depends on some environment variables that weren't being passed through in strict mode. I've added these to the allowlist.

If the issue persists, then please provide the underlying tool you're using along with the values of TERM and COLORTERM in your shell.

@jraoult
Copy link

jraoult commented Jun 14, 2024

@chris-olszewski just to be clear, because I realise this can be confusing since this issue mentions two problems (that may be unrelated): from my side I can see the colours but the link to the code doesn't work.

With that in mind, I tried 2.0.4-canary.4 and sadly no improvement for me for the linking part.

My env: echo $TERM yields xterm-256color (and no COLORTERM for me).

@MickL
Copy link
Author

MickL commented Jun 14, 2024

I tried 2.0.4-canary.4 within Webstorm and I see colors now :) Just lines of code are not clickable still

Bildschirmfoto 2024-06-14 um 14 17 27

@chris-olszewski chris-olszewski removed the needs: triage New issues get this label. Remove it after triage label Jun 14, 2024
@nsimonson
Copy link

Workaround that seems to work for me to enable colors is to set FORCE_COLOR. Given the changes to strict mode in v2, you'll need to make sure to add it to globalPassThroughEnv.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: bug Something isn't working owned-by: turborepo
Projects
None yet
Development

No branches or pull requests

6 participants