Improve require speed

[stroncium]

• Lazy load templates(runtime overhead should be zero due to prototype check overlapping with === undefined check)
• Don't access ansi-styles color space converters unless needed

This patch works in conjunction with(but works without them too, though to much smaller effect):

• Lazy load color converters ansi-styles#53
• Avoid triggering stdio streams creation supports-color#101

Require speed test results before:

Require speed test results after(pure require, without using template nor color conversion functionality):

Note: in both cases, a huge part of time is spent initializing tty(or initializing process.stdout and process.stderr, which includes initializing tty), which is also triggered by a lot of other parts of stdlib(for example by console.log with non-string arguments), and is required in order to detect if output supports color, so is expected to be initialized anyway by a lot of real life programs(notable exception: programs which conditionally produce no output). If we subtract the time required for this initializations, the final numbers will be ~10ms and ~5ms, respectively.

Fixes #180

---

IssueHunt Summary

Referenced issues

This pull request has been submitted to:

• #180: Improve require speed

---

IssueHunt has been backed by the following sponsors. Become a sponsor

[stroncium]

With newer version of nodejs(I tested on 12.10.0) all the require speeds increased quite a lot and tty require speed increased dramatically(6.0ms => 3.8ms), so I'm currently getting 6.4 ms total require time with 3.8 going to tty on the same machine. (Too lazy to relink all the stuff to compare with results prior to all the fixes here and in deps.)

With this in mind, I think inlining basic color converters in this module to reduce require time even further doesn't really make sense anymore, as the gains should be minor. So I consider the patch complete in terms of functionality. (Though it still makes some sense to do in general, but can be implemented in ansi-styles.)

[ExE-Boss]

Since we’re removing undocumented colour spaces, this is probably a breaking change.

[stroncium]

@ExE-Boss changes in undocumented features is not considered API change, and not a breaking one for sure. Though in any case this code is scheduled for chalk 3.0 release as far as I understand.

[sindresorhus]

@stroncium Can you fix the merge conflict?

[sindresorhus]

Awesome. Thanks for working on this 🙌

[Turbo87]

@stroncium out of curiosity: what tool did you use to create that terminal screenshot in the PR description?

[stroncium]

@Turbo87 That would be my private tool for node performance metrics and optimization. Didn't get to write docs for it and release publicly yet, sorry.