ANSI code stripping should be optional

[joepie91]

Currently, ANSI escape codes are always stripped by this library. However, there are plenty of contexts where one might be interested in the 'real' character count of a string, but where ANSI escape codes do not have a special semantic meaning, and so stripping them would result in an incorrect character count.

IMO, the ANSI code stripping should either be opt-in, or possibly even considered out-of-scope for this module entirely - since one can also just call strip-ansi on the string before passing it in, or whichever stripping function is appropriate for their specific semantic context.

[sindresorhus]

The current behavior is like this because my use-cases always required stripping ANSI escape codes. If you provide some good use-cases where stripping ANSI escape codes are not wanted, I'm open to adding an option to not strip such codes.

[joepie91]

The original usecase for which I was looking at this library (which is for a client), is name length limit validation in a network protocol. There's no terminal involved there, and so 'escape codes' would just be characters (printable or otherwise) like any other.

Another usecase which I'd like to use this library for is my own validation library, as a specifically string-aware equivalent of the has-length-of and has-length-between validators (which currently just look at .length and are agnostic to the exact input type).

In that case it would need to be usecase-agnostic, because people may use the validator for any purpose, including things like form validation, external API response correctness checks, protocol message validation, and so on - all of which are not terminal-related usecases, and so the escape codes have no semantic meaning there, as I understand it anyway.

[sindresorhus]

Thanks for elaborating. Makes sense. PR welcome to add such an option. I don't want to do a breaking change now just for this, but we can change the default next time we have to do a breaking change.