Chalk: Bold resets previous color

[Elberet]

Depending on order and type of operations, bold causes a previously set color to be suppressed:

chalk.bold("foo") => '\u001b[1mfoo\u001b[22m'
chalk.blue.bold("foo") => '\u001b[94m\u001b[1mfoo\u001b[22m\u001b[39m'
chalk.bold.blue("foo") => '\u001b[1m\u001b[94mfoo\u001b[39m\u001b[22m'
chalk.bold.hex("#0000ff")("foo") => '\u001b[1m\u001b[38;2;0;0;255mfoo\u001b[39m\u001b[22m'
chalk.hex("#0000ff").bold("foo") => '\u001b[38;2;0;0;255m\u001b[1mfoo\u001b[22m\u001b[39m'

The screenshot above was taken on Windows 10 1709 (Enterprise) using Node v10.13.0 through winpty 0.4.3 in mintty 2.8.1 installed with Git for Windows. Running node via Powershell or cmd yields identical ANSI sequences and similar results, as far as the coloration of the last sample is concerned, e.g.:

[Qix-]

Running node via Powershell or cmd yields identical ANSI sequences and similar results, as far as the coloration of the last sample is concerned, e.g.:

I think you answered your own question there - this is a bug with mintty, not Chalk.

[Elberet]

Hm, maybe I didn't express myself clear enough. Sorry.
Running the tests in other consoles produces the same ANSI sequences as in mintty; those same ANSI sequences produce the same and incorrect colors; mintty, cmd and PowerShell behave the same. (Or rather, they behave comparably; e.g., bold + hex yields bright yellow text in PowerShell, likely because that's PowerShell's default prompt color; that result is independent of the value passed into hex(), at least.)

Also, note that in the second image the last two test strings are unfortunately flipped, but both images - mintty and cmd - show that

• bold + hex → non-bold, correct color
• hex + bold → bold, incorrect color

I do agree, however, that this probably isn't a bug in chalk, but an odd quirk in how the Windows terminal chooses to interpret those color changes. Also, I'm assuming that there's a general consensus that for one, preserving the color information is more important than preserving the boldness, and two order of operaton should not matter here -- so chalk may want to implement some workaround. :wink:

[Qix-]

Sorry, should have looked closer. The codes are correct, I believe Microsoft has fixed a lot of these but they haven't been released yet.

See visionmedia/debug#683 for something quite similar, if not the same - namely this comment.

[sindresorhus]

Closing as this is not actionable for us and it's not something we're interested in working around. Instead, open an issue on the relevant terminals.