Does not support keyword

[jedahan]

When I switched from chalk to ansi-colors, I couldn't use ansi.keyword('hotpink') like I was using in chalk.

Not a big deal (a little sad as I liked hotpink, but red is fine), but I would suggest removing the 'drop-in' qualifier, either removing it completely or replacing it with something like 'simpler'. Maybe removing the bullet-point in the readme.

That or adding .keyword support. Cheers!

[jonschlinkert]

Not a big deal (a little sad as I liked hotpink, but red is fine), but I would suggest removing the 'drop-in' qualifier, either removing it completely or replacing it with something like 'simpler'. Maybe removing the bullet-point in the readme.

We're considering supporting more colors since we can do it with a lot less code than chalk. If not we'll change it to "drop-in replacement for chalk with all standard ANSI styles". Which I think is what 99% of users already assume is meant by the description.

[jedahan]

I'm not sure where the 99% statistic comes from, but when I see 'drop-in' the implication is that there is api parity - that there is the potential to switch to a safer/faster/less buggy implementation without changing client code. Honestly I think the project stands on its own better without comparisons to chalk and kleur but if keeping the 'drop-in replacement' verbiage is key I feel like its misleading until any or all of the following is done:

• clearly state what function calls are supported and what are not in the docs
• implement stubs for api calls that are deprecated so errors are not thrown when ansi-colors is dropped-in
• implement the full api so you truly can s/chalk/ansi-colors/

I am not sure what scope the project wants to be, maybe all the truecolor stuff should be another module, maybe ansi-colors wants to incorporate all the truecolor stuff itself, etc, which is why I am mentioning all these options instead of advocating for a particular one.

Hope this context helps clarify why I was surprised.

[jedahan]

As example of something similar ~ https://github.com/micromatch/micromatch#switching-to-micromatch

[jonschlinkert]

I'm not sure where the 99% statistic comes from

Sorry, I didn't mean to casually throw around numbers. Allow me to clarify.

Given that:

1. Statistically, this library is depended on by ~175-200 libraries.
2. On average across industries, it's estimated that 1 in 20-25 people that have a problem will actually complain (or let someone know) that they're unhappy. This, obviously, is a rule of thumb and we have no way to know if this is accurate, but it's based on various studies over the years, and you can find information about these if you spend some time on google looking for them.
3. I believe, based on experience, that because of the ease of creating an issue and the fact that the ecosystem encourages it, and that issues cause other people's code to break, far more developers tend to speak up about them than the average industry. I'm guessing as many as 30-50%.

Since this is the first issue that someone has created about a feature that is in chalk but is missing from ansi-colors, I can say with confidence that only 1 in 175 implementors have definitely had the problem you experienced. It might be more, but I don't have proof of that. It's safe to assume that if no one else had the same problem, that they - like me - are not using the other "non-standard" ANSI colors, and would be unlikely to notice what you did in the readme.

With all of that in mind, I supposed should have said, "based on the actual facts on hand, we can assume that approximately ~99.5% of developers do not use the other features in chalk OR did not care enough about them to complain. Which means that ansi-colors is a drop-in replacement for 99.5% of people." If we assume that half as many people report issues than my estimate above, then it would be ~99%.

• clearly state what function calls are supported and what are not in the docs

It's a certainty that someone like you will create an issue anytime we're wrong on the readme, so this was not omitted intentionally. We looked at chalk a long time ago, and I don't remember seeing any of the other stuff that has been added to the chalk API since. IMHO, there was no reason to look again, since it was a relatively simple library that did one thing (or so I thought). Thank you for pointing out the disparity. we will get the readme updated.

[rootwork]

FWIW between this and #40 I agree that having it described as a "drop-in replacement" is unnecessary and not really true. I was using named keywords and hex values and had to change them when I adopted this package. But ansi-colors is great, and as @jedahan says the project stands on its own without that comparison anyway.