Closed rauchg closed 12 years ago
Thanks for suggestion.
Let me think about, I can see that it might be useful, however I assume it will be highly unwelcome if some reusable packages will start using cli-color that way - using external packages that extend native object's prototypes may collide with extensions that someone's setup on his own in his application.
I'll probably add such option, with some warning notice in documentation.
I'm about to unleash v0.2, and now I can say this proposal doesn't make much sense in scope of cli-color.
To achieve that I would need to write new functionality nearly from scratch (not much reuse is possible). Other important thing, one of the main reasons I wrote cli-color was to have good console color library that doesn't touch built-ins, so introducing such opt-in would be controversial, also it wouldn't add any new feature to the library
There's one library that does exactly what you ask for: https://github.com/Marak/colors.js so I guess it's good to leave it the way it is. If some prefer to have methods setup directly on String.prototype, there's alternative.
Thanks!
It would be cool to have to ways of requiring it:
and
The first one would extend
String.prototype
and expose the same methods: