There is no cleverness involved. The escape sequences are decades old and universally supported as a de facto standard. In this case the escape sequences are assigned to variables that are attached to other strings. This is as clever as using an operator. These escape sequences are even supported by Chromes dev tools console directly in the browser.
The real issue is invented here syndrome. People irrationally defer to libraries to cure their emotional fear of uncertainty. For really large problems, like complete terminal emulation, I understand that. However, when taken to an extreme, like the left pad debacle, it’s clear people are loading up on dependencies for irrational reasons.
I despise these microlibraries as much as anyone, but your solution will also print escape codes when they're not needed (such as when piping output to e.g. grep). If it's something that makes sense only in interactive mode, then fine, but I've seen enough broken programs that clearly weren't designed to be run as a part of a UNIX shell, even when it makes a lot of sense.
It's easy to solve though, simply assign empty strings to escape code variables when the output is not an interactive shell.
Yes, the tree view of dependencies in pnpm breaks my terminal environment when I attempt to pipe it through |less. Several JS related tools seem to have this undesirable behavior. I assume most users never view dependencies at that depth or use a more elaborate tool to do so. I found this symptomatic of the state of the JS ecosystem.
That is not a string output problem. That is a terminal emulator problem. It is not the job of an application to know the modes and behaviors of the invoking terminal/shell. This applies exactly the same for all other applications that write to stdout. There is no cleverness here. But, if you really really want to avoid the ANSI descriptors for other reasons, maybe you just don't liked colored output, my applications features a no-color option that replaces the ANSI control string values with empty strings.
The terminal emulator is not involved in piping to other processes. Grep will search over escape codes if you don’t suppress them in non-interactive environments, so this most definitely is a string output problem.
If you want to do it yourself, do it right—or defer to one of the battle-tested libraries that handle this for you, and additional edge cases you didn’t think of (such as NO_COLOR).
How do you define battle tested?
Typically JS developers define that as assuming something must be safe if enough people use it. That is a huge rift between the typical JS developer and organizations that actually take security more seriously. There is no safety rating for most software on NPM and more and more highly consumed packages are being identified as malicious or compromised.
If you do it yourself and get it wrong there is still a good chance you are in a safer place than completely throwing dependency management to the wind or making wild guesses upon vetted by the community.
I mean we’re talking about libraries to format strings here, not rendering engines. If you doubt the quality of such a lib, go read the source on GitHub. That’s what I usually do before deciding if I install something or implement it myself.
Lots of applications use isTTY to determine how they output FYI
It is 100% the job of the application. This is why a lot of programs have options like --color=auto so it infers the best output mode based on the output FD type e.g. use colours for terminals but no colours for pipes.