multiple chalk functions share the same _styles array

I’d been doing this with chalk 0.4:

var COLORS = {
  INFO: chalk.bold.green,
  WARN: chalk.bold.yellow,
  ERROR: chalk.bold.bgRed,
  // etc
}

Upgrading to 0.5, I find that all of the functions I’ve stored are all set to apply the styles of the last on in the object.

[seanmonstar]

As I fiddle on a patch for this, I can’t think of a way of providing the same API with the same performance. Each getter needs to return a new object (a function), and that function needs to have all the getters set. Object.defineProperty is brutal in a loop. Here’s the options I see:

1. Live with the performance hit of defining getters on each function. It’s not bad at all if you cache the style into a variable, such var style = chalk.blue.bgRed.bold, since subsequent uses of style won’t be triggering new definePropertys. I’ve added a benchmark that shows with the style cached into a variable.
2. Get ~8x performance of option 1, by setting __proto__ on the function to an object with the properties already defined. __proto__ is deprecated, in ES6 it will become Object.setPrototypeOf, but it can’t be remove any time soon if they don’t want to blow up the web. The docs for __proto__ state that it hurts performance, but comparing the benchmark with using Object.create() and chalk.red._('foo') showed it was actually slightly slower than this __proto__ hack.
3. Say to hell it with Sean, just call everything off chalk (this is still much slower than caching a couple styles).

Here’s the benches with option 2 (and an optimization of not doing [].slice.call(arguments):

before
                      chalk
       1,286,288 op/s » single style
         943,220 op/s » several styles
         245,858 op/s » nested styles

after
                      chalk
       1,341,294 op/s » single style
         254,177 op/s » several styles
       1,843,002 op/s » cached styles
         298,379 op/s » nested styles

[jbnicolai]

Same here 😃 let me have one last look and I’ll merge it in