@TiagoDanin Can you help review?

Can we add a few cases where string.normalize() would change the input string, too? I want to make sure that won't break anything.

Good catch, that actually breaks stuff. I wrote the code that included the normalization, but now that I think of it, I don't see why we need it. It'll only modify the string to use a different character than the one inputted. Also, all the tests passes without normalization as well.

'\u006E\u0303test' === '\u006E\u0303test'.normalize();
//=> false

It doesn't break anything, except that if you're going to compare the output with your input some characters might differ.

I agree, we shouldn't care about it. It's another linear sweep of the string, anyway, so it's a win-win. Let's remove it ^^

I'll do it in a separate PR though since it's unrelated to this.

I found a big problem.
The support fullwidth characters ( #4, #9) does not work with ANSI combination.

\u001B[31m古古test\u001B[39m does not return the \u001B[31m

UPDATE:
Sugestion

if (!astralRegex({exact: true}).test(character) && isFullwidthCodePoint(character.codePointAt())) {
			++visible;
			++begin;
			++stringEnd

			if (typeof end !== 'number') {
				++stringEnd;
			}
		}

This should fix.

Bus this break the test 'supports fullwidth characters', I believe that here "안녕하세" (

@TiagoDanin, could you provide a test example?

@TiagoDanin, that's no bug, you're starting to slice in the middle of a full width character. This works:

t.is(sliceAnsi('\u001B[31m古古test\u001B[39m', 2), '\u001B[31m古test\u001B[39m');
t.is(sliceAnsi('\u001B[31m古古test\u001B[39m', 2, 4), '\u001B[31m古\u001B[39m');

This is also how I'd expect this library to work. If we were to treat full width characters as "single" characters, I'd add an option for it but it's out of scope of this issue.