Because we no longer downsample ansi is no longer active, level 1 is now effectively the same in function as level 2.

Just curious, why aren't we downsampling anymore? That seems like a functional regression, given that there are still loads of terminals that only support the older 16 color palette.

@sindresorhus first suggested to remove it: #300 (comment)

Then you in a seperate conversation, approved removal of ansi: #300 (comment)

I don't see in there why we need to remove this functionality. I would say we should inline that from color-convert (you're free to copy over the ansi256.ansi16 function from conversions.js directly - not that the license would have prevented you anyway). Just mention it came from color-convert in a comment.

The concern about upscaling (#370) was valid, but downscaling is absolutely necessary to keep compatibility with people who do not have 256 support.

As for the comments about "removing" that - no, those say to remove color-convert and thus the majority of the conversion models, save for hex and rgb. I strongly believe we need to keep ansi256 as well, and be able to downsample to 16-colors if necessary.

cc @sindresorhus

• If chalk is at level 1 and I give it an .rgb(), it should downsample.
• If chalk is at level 2 and I give it an .rgb(), it should downsample.
• If chalk is at level 1 and I give it an .ansi256(), it should downsample.
• If chalk is at level 2 and I give it an .ansi256(), it should pass through.

If we remove downsampling, we're going to irreparably break a LOT of people.

you're free to copy over the ansi256.ansi16 function from conversions.js directly - not that the license would have prevented you anyway

That function doesn't exist

Right, you have to merge them - this is untested but should be close enough. Just needs a bit of polish for the Chalk conventions.

function ansi256To16(args) {
	if (args < 8) return 30 + args;
	if (args < 16) return 90 + (args - 8);

	let r, g, b;

	// Handle greyscale
	if (args >= 232) {
		const c = (args - 232) * 10 + 8;
		r = g = b = c / 255;
	} else {
		args -= 16;

		let rem;
		r = Math.floor(args / 36) / 5;
		g = Math.floor((rem = args % 36) / 6) / 5;
		b = (rem % 6) / 5;
	}

        const value = Math.max(r, g, b) * 2;

	if (value === 0) {
		return 30;
	}

	let ansi = 30
		+ ((Math.round(b) << 2)
		| (Math.round(g) << 1)
		| Math.round(r));

	if (value === 2) {
		ansi += 60;
	}

	return ansi;
}

Then just make a bunch of test cases as such:

// Just as an example.
const colorConvert = require('color-convert');
const assert = require('assert').strict.ok;
const {ansi256To16} = require('..');

// Start at 16 since color-convert hasn't been updated to
// correctly return the first 16 colors of ansi-256.
for (let i = 16; i < 256; i++) {
	assert(
		colorConvert.ansi256.ansi16(i) === ansi256To16(i)
	);
}

Support for ansi has been added back in.

I'm confused. I understand preserving the downsampling, but shouldn't we still remove the explicit .ansi() method?

IMO, there is no impact of leaving the function there so we might as well leave it for people wanting to use the ansi color space. However, I agree that its utility is quite rare but this argument could also be held for ansi256 since it is also a step down from rgb.

People wanting to use the ansi color space should just use .red(), .blueBright(), etc as it's a 1:1 mapping. People doing programmatic generation of colors for whatever reason are going to be using 256 or truecolor - not 16 - as there is no logical rhyme or reason to the code (I always remember them as "traffic light, dark blue, pink, light blue, white" - completely arbitrary).

I agree with sindre here - no need for .ansi(). Chalk is a utility library, after all - you're always able to write escapes yourself with trivial syntax.

See also: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

Removed

Nice work, @Richienb 👍

Yes indeed :) Thanks @Richienb, super appreciated.