Closed ELLIOTTCABLE closed 10 years ago
It's trickier for it to be a direct fork and address the core performance issues. The module is just one file and I had to use a different approach. FWIW, the module require
s chalk and then uses it after the first two levels of chaining. I also don't anticipate big changes in the chalk API -- the terminal isn't really evolving much these days. The biggest possible thing would be 256 color support, and the chalk author indicated a desire to keep that out of chalk, so I think that if this is compatible now, it should be a safe bet that it will be compatible for the long term.
If you have a clean way of forking chalk and getting the same benefits, feel free to suggest/submit a patch.
Mmmm, just a suggestion.
I'll take a look!
I'd be more compfortable using this module if it were a straight fork of
chalk
, with a pending pull-request to include the changes intochalk
. Even if she's not intending to merge it, using an alternative to such a large, established library, when the alternative is so similar, is scary: if this were a direct fork, it'd make it easy (were you to abandon your work here) for others to merge your changes into their own forks; thus allowing us API consumers to remain hopeful that using your work would be a sustainable choice in the long-term. (=