Progress bar doesn't render correctly in Visual Studio Code's terminal panel

[redstrike]

Do you want to request a feature or report a bug?
Not sure.

What is the current behavior?
yarn is very buggy, slow while running. And the progress bar auto line breaks itself looks ugly.

If the current behavior is a bug, please provide the steps to reproduce.
yarn install / yarn upgrade

What is the expected behavior?
A progressive and good looking progress bar.

Please mention your node.js, yarn and operating system version.

• Windows 10 Pro x64 v1607
• node v6.9.0
• yarn v0.16.0

This bug still happens until now 2017/05/15:

• Windows 10 Pro x64 1703 (OS Build 15063.296)
• node v7.10
• yarn v0.24.4

[Daniel15]

Can you please post a screenshot of what the progress bar looks like for you?

This is how it's supposed to look (cmder on Windows 10):

[mnpenner]

Out of curiosity, I tried it in cmd.exe. Works fine there too:

Same with ConEmu.

[redstrike]

@Daniel15, @mnpenner : I have tried to test yarn on cmd and PowerShell, the progress bar works normally. However, yarn's progress bar seem have some problems with Visual Studio Code 's Terminal Panel.

• VS Code v1.6.1

[mzvast]

On my machine ,all displays incorrect,including cmd, powershell, gitbash.
info:
(Windows 10 Pro x64 v1607
node v6.9.1
yarn v0.16.1)

[fluxxu]

I think this is related to font
If I change font to MS Gothic, the progress bar looks normal:

But this font is unusable :(

(Windows 10 Pro x64 v1607
node v6.9.1
yarn v0.16.1)

[mnpenner]

I'm pretty sure this just means VS Code is not processing the \r (or whatever yarn uses to re-draw the progress bar) correctly.

It's not a Windows issue, a PowerShell or Cmd.exe issue, nor a font issue.

If this is indeed the problem, I would file the issue with them (VS Code), not Yarn.

However, Yarn should have an option to disable the progress bar for improved compatibility if it doesn't already.

[Daniel15]

I'm pretty sure this just means VS Code is not processing the \r (or whatever yarn uses to re-draw the progress bar) correctly.

@mnpenner - It uses readline.cursorTo to reposition the cursor at the start of the line, which internally uses ANSI escape codes.

[mzvast]

I found a way to avoid this problem on my Chinese win 10 terminal, that is to set the "Active Code Page" to 437(us-en) or 65001(UTF-8).Just type chcp 437orchcp 65001.
This problem may have something to do with the windows charset in console.So non-en system users are more likely to suffer this issue.

Yarn is fine, VS code is fine, windows old terminal's charset's bad!

[andykais]

A very similar issue is affecting docker containers using yarn commands

I would like to either see a permanent --no-progress option or a common fix for the problem. (I tried generating locales and setting LANG=C.UTF-8 in the container to no avail

[redstrike]

VS Code v1.9.0 has many improvements including its integrated terminal (Powershell has replaced cmd). This bug is no longer happen in VS Code (if we don't resize VS Code's window while the progress bar is running).

[herecydev]

@redstrike I disagree, whilst it's not broken as hell. It's still not perfect, it's too large and still has some areas that "stick" around for a little while before disappearing. It's really hard to describe without recording it.

[irfinnew]

I'm seeing a similar issue on some but not all Linux hosts:

Strace shows that yarn emits \33[1G (moving the cursor) between iterations of the progress bar when it works properly, but fails to emit this when it's not working.

Some digging lead me to the COLORTERM environment variable. It appears that yarns progress bar is messed up where that variable is missing. It works correctly when I run COLORTERM=rxvt-xpm yarn install.

It looks like this is a bug in yarn (or whatever yarn uses for the progress bar); not emitting the cursor-moving control sequences when an optional environment variable is missing.

If all else fails, may I suggest simply using \r?

[aalpgiray]

same here on version 1.12.1

[redstrike]

OMG! yarn is buggy again on the latest stable version: 0.24.4 😭

Windows 10 Pro v1703 (OS Build 15063.296)

[xakep139]

Same problem, npm 4.3.0, node 7.7.2, Yarn 0.24.5, Windows 10 Enterprise 1703 (build 15063.296)

Separate powershell process works fine

[xakep139]

There is similar issue with Jest: jestjs/jest#3626

[snewell92]

Yarn was working for me fine last week, this week it seems I am also experiencing this issue as well. Here is my environment, hopefully can help track it down/repro.

Windows 10Pro 64-bit Version 10.0.15063 Build 15063.

[xakep139]

Another glitch with yarn in VS Code: microsoft/vscode#24604

[xakep139]

Apparently, it is not Yarn issue: microsoft/vscode#19665
It seems like there is a bug in Windows with Creators Update, KB4020102 should fix this bug

[aalpgiray]

unfortunately "KB4020102" did not fix the issue for me .

[Daniel15]

@mmoreaux

It looks like this is a bug in yarn (or whatever yarn uses for the progress bar); not emitting the cursor-moving control sequences when an optional environment variable is missing.

This would be Node.js' readline.cursorTo function.

[xakep139]

Progress bar is now fixed for me after installing KB4020102 and updating VS Code to 1.13.0

[redstrike]

It seems that Unicode character width improvements in VS Code 1.13 has fixed this issue.

[snewell92]

Woo! :D The issue can be closed now. 👍 🎉 Now efforts can be focused on the other issue!

[irfinnew]

No, the issue cannot be closed; the issue @xakep139 started talking about is different from the issue described in the starting post (different type of corruption, and the issue from the OP also happens on non-Windows hosts).

[ahundt]

I can confirm this bug appears on OS X and Linux just like the other screenshots/videos with the Keras Progbar on 1.13.1.

[tech4him1]

This bug still happens with Yarn 1.0.1 in Windows 10 (PowerShell and cmd) with some fonts.

[BYK]

I think this is a duplicate of #2530, right?

[redstrike]

@BYK
No, it's not. I created this issue since Oct 19, 2016.
So, I think that you have to say #2530 is a duplicate of this issue :)

[BYK]

@redstrike I was afraid of this when I wrote that comment! :D It is also obvious from the issue numbers that this is the "original" issue. That said the other one has a PR attached and it is more generic so I was implying that closing this in favor of that.

If you are too attached to this one, we can close them at once with the PR though :D

[redstrike]

Thank you for your support. We can close this issue to ease your management efforts.
Please help me do it and reference to new issue ;)

[BYK]

Will do :)

[BYK]

This was fixed by #4317.