lukeed/kleur

The fastest Node.js library for formatting terminal text with ANSI colors~!

kleur's Issues

Potential benchmark flaws

I've noticed two potential flaws with the benckmarks used. I ran all benchmarks on the LTS version of node (v14.17.0) and used import instead of require. I also included the colorette package from #44.

1. The load time of all libraries is essentially the same, but the library that's placed first will be significantly slower. An example where kleur was moved to the top is below.

# Load Times
  kleur         x 65μs
  kleur/colors  x 4μs
  chalk         x 4μs
  ansi-colors   x 4μs
  colorette     x 9μs

Also, it appears that console.time() has significant overhead. When I used process.hrtime.bigint() instead, I got much faster results:

# Load Times
  kleur         x 5.4μs
  kleur/colors  x 0.7μs
  chalk         x 0.9μs
  ansi-colors   x 0.8μs
  colorette     x 1μs

2. When you import the entire module, both kleurs/colors and colorette perform much worse in the first test.

# All Colors
  ansi-colors   x 166,182 ops/sec ±0.96% (90 runs sampled)
  chalk         x 710,172 ops/sec ±2.34% (83 runs sampled)
  kleur         x 857,874 ops/sec ±2.88% (85 runs sampled)
  kleur/colors  x 251,574 ops/sec ±0.77% (85 runs sampled)
  colorette     x 234,007 ops/sec ±0.80% (89 runs sampled)

I believe this is due to the import * as colors from "lib"; syntax, but that's just a guess. I have no time nor expertise to look further into it.

Can't upgrade to Kleur@3 (error message from hell)

The last two days i get the deprecated message ...and I don't want to "suffer the deprecation notice on older kleur versions". But I cant install it following the install instructions. The deprecation notice just returns next time I try to install something.

And I don't even know what this kleur is or why I have it or why I need it. Or if I should install it??

How about add turbocolor in benchmarks?

Seems turbocolor is faster in its benchmarks :)

Question: kleur instances

Hi Luke,

is there any way to create an instance of kleur?
In Moleculer loggers I have an issue with enable/disable coloring because all loggers use the same imported kleur instance.

Use case: There are two loggers, first is a console logger which enables colors and prints the messages with colors, the second is a file logger which disabled the colors, but both of them use the same kleur so the colorizing works weird.

Do you have any idea, how I can solve it?

Thanks in advance!

Updating benchmark

Hi,

I recently noticed that chalk published a new major release (v3) (with a good enhancement around performance issues). And ainsi-colors is v4 now too.

Benchmark result on my computer

# All Colors
  ansi-colors x 144,685 ops/sec ±1.63% (86 runs sampled)
  chalk x 475,976 ops/sec ±2.17% (85 runs sampled)
  kleur x 551,656 ops/sec ±2.41% (86 runs sampled)

# Stacked colors
  ansi-colors x 19,153 ops/sec ±1.10% (86 runs sampled)
  chalk x 367,395 ops/sec ±3.02% (79 runs sampled)
  kleur x 66,077 ops/sec ±1.47% (83 runs sampled)

# Nested colors
  ansi-colors x 53,458 ops/sec ±0.81% (88 runs sampled)
  chalk x 95,860 ops/sec ±1.86% (86 runs sampled)
  kleur x 105,228 ops/sec ±0.98% (88 runs sampled)

Sorry to open issue for that kind of stuff ^^. But I told myself that anyway someone would surely come one day for this haha :)

Best Regards,
Thomas

Do we have an API to create a different kleur instances

For Logux I need a way to have color output in one part and not having it in other.

const a = new HumanReporter({ color: false })
const b = new HumanReporter({ color: true })

a.print()
b.print()
a.print()

Do we have in Kleur a way to do it?

Enabled should be determined on demand

Ideally, the environment should be checked for color support every time kleur is used, because environment variables can be changed at runtime. At the moment, the enabled property is determined once at module load time:

kleur/index.mjs

Lines 3 to 12 in fc9cc25

	let FORCE_COLOR, NODE_DISABLE_COLORS, NO_COLOR, TERM, isTTY=true;
	if (typeof process !== 'undefined') {
	({ FORCE_COLOR, NODE_DISABLE_COLORS, NO_COLOR, TERM } = process.env);
	isTTY = process.stdout && process.stdout.isTTY;
	}
	const $ = {
	enabled: !NODE_DISABLE_COLORS && NO_COLOR == null && TERM !== 'dumb' && (
	FORCE_COLOR != null && FORCE_COLOR !== '0' || isTTY
	),

We should be able to set process.env.FORCE_COLOR = '1', run a snapshot test of some colorized output, then revert the FORCE_COLOR environment variable back to what it was again. At the moment doing this causes snapshot tests to fail in a GitHub Actions CI environment, as the process is not a TTY when the kleur module is loaded causing kleur.enabled to be false and setting FORCE_COLOR to 1 at runtime makes no difference prior to calling kleur.

Breaking changes (regression ?) with kleur 3.0.3

Hi,

I recently upgraded dependencies on one of my CLI packages and noticed that the colors was broken (see below example with before/after).

Before update (3.0.2) https://imgur.com/XLiEhxq
After update (3.0.3) https://imgur.com/KGamCXm

My packages is open if you want to check yourself: https://github.com/fraxken/dep-updater

I feel that my first bold green is not reseted and applied by default to all others (something like that).

Best Regards,
Thomas

Make it available in pika cdn

Would be great if kleur would be web module compatible, so I can use it with pika.dev.

https://www.pika.dev/search?q=kleur

Missing bold import in nested methods example

https://github.com/lukeed/kleur#nested-methods

const { yellow, red, cyan } = require('kleur');

console.log(yellow(`foo ${red().bold('red')} bar ${cyan('cyan')} baz`));
console.log(yellow('foo ' + red().bold('red') + ' bar ' + cyan('cyan') + ' baz'));

custom colors

is it possible to define custom color methods, like mycolor and bgMycolor to use B263F7 for example?

do not define a valid './colors' target

Module build failed (from ./node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ./node_modules/postcss-loader/src/index.js):
Error: Loading PostCSS Plugin failed: Package exports for '/xxxx/node_modules/kleur' do not define a valid './colors' target

Builtin color-support detection

Nice package!

Just a little annoying issue, testing for cli usually running in a non-colored shell, I have to disable it manually in testing, then found I have to do it in every package switched from chalk to kleur > <

What about considering builtin color-support detection?

Export interfaces in definition file

Hi, there great lib!

Currently, only the object signature Kleur & { enabled: boolean } is exported, it would be nice to also be able to access the interfaces for Kleur and Color directly.

Unexpected reset behavior

With this code:

const kleur = require('kleur')

console.log(kleur.red(kleur.reset('a' + kleur.blue('b') + 'c')))

The result is that the last character logged is unexpectedly red, when it should be default (black):

Using kleur as tagged function returns array-like string

I'm planning to switch from chalk to kleur on markcat but when testing kleur to see if I could do a simple "replace all" I came across the next bug (don't know if its actually a bug since I didn't read the code to understand it)

When doing everything works as expected:

const kleur = require('kleur')
const text = kleur.red(`Hello World`)
Buffer.from(text) // <Buffer 1b 5b 33 31 6d 48 65 6c 6c 6f 20 77 6f 72 6c 64 1b 5b 33 39 6d>

But when I use kleur.red as a tagged function I get the following:

const kleur = require('kleur')
const text = kleur.red`Hello World`
Buffer.from(text) // <Buffer 1b 5b 33 31 6d 5b 20 27 48 65 6c 6c 6f 20 77 6f 72 6c 64 27 20 5d 1b 5b 33 39 6d>

which looks like a red string (the typeof is string indeed) that says [ 'Hello World' ].

Kleur crashes when there's a global variable keys

Hi! My app uses global.keys constant. Unfortunately, it conflicts with Kleur internal magic.

function init(key) {
	return function (txt) {
		let isChain = !!this.keys; // <<<
		...
	};
}

As global.keys becomes something different:

this.keys.includes is not a function
    at /.../node_modules/kleur/index.js:95:26

I guess that's how you detect chaining. Is it possible to use "use strict" pragma and check if this is undefined instead of relying on global object field (which is not safe for libraries)?

grey alias

I know this is just a small issue. I just converted from chalk to use kleur. However it would be nice to have grey in the list.

Bright colors

is it possible to add bright (brightBlue, etc.) versions of the colors?

Add blinking

Can we have blinking as a modifier?

https://stackoverflow.com/questions/17439482/how-to-make-a-text-blink-in-shell-script

Documentation Translation （Lang: zh-CN）

Hello, I am a developer from China. I like this library very much and have translated the documentation, hoping to better recommend it to the majority of Chinese developers.

Here is the link

I wish you can put it into the official document.

PS. 中文文档 means Chinese Documentation

Thank you very much

test mode

When testing sometimes there is need to snapshot messages that might have colour in them. Colour is a concern for DX and has a valid reason to be captured in the snapshots. E.g. avoid colour regressions after refactoring.

It seems that colours codes differ across Node 12/14. graphql-nexus/nexus-prisma#3 (comment).

Anyways, it would be nice to have a test mode where instead of escape codes a nice human-readable string were emitted, like __RED__ or RED or KLEUR.RED.

This would generally be much richer to read in snapshots.

Add `colorette` to benchmark comparison

Just found the lib colorette while looking through the create-stencil lib. I noticed that they were showing a benchmark in theirs that included your library but appears to be an older version.

I think it would be helpful to have their library included in your benchmark.

Side Note: It would be useful to have at least the major version of the library you are benchmarking against.

NO_COLOR implementation doesn't match the spec

NO_COLOR is meant to disable color regardless of the value:

All command-line software which outputs text with ANSI color added should check for the presence of a NO_COLOR environment variable that, when present (regardless of its value), prevents the addition of ANSI color.

i.e. all of the following should disable color:

$ NO_COLOR=1 command  # ✔ 
$ NO_COLOR=0 command  # ✔
$ NO_COLOR= command   # x
$ NO_COLOR="" command # x

But the current implementation expects it to be truthy:

kleur/index.mjs

Line 10 in b08ad63

enabled: !NODE_DISABLE_COLORS && !NO_COLOR && TERM !== 'dumb' && (