Further size optimization

[borodean]

This PR makes picocolors.js 118 bytes smaller (17 bytes smaller after GZip). Here is a break-down of every change:

Commit	Description	Size	Size after GZip	Savings	Savings after GZip
6d3b212	Convert named functions to arrow ones	2600 B	737 B	−44 B	−4 B
89cef1f	Reorganize functions code to make them shorter	2565 B	733 B	−35 B	−4 B
22392c3	Embed createColors to the default export directly	2537 B	728 B	−28 B	−5 B
59df46d	Reorganize isColorSupported to make it shorter	2526 B	724 B	−11 B	−4 B
Total				−118 B	−17 B

[ai]

It has a different meaning. Empty string will not lead to false, but it leads to true before.

[ai]

API changes. createColors().createColors was undefined before.

[alexeyraspopov]

This most likely affects benchmarks. I tried to use ternary operator within a concat expression and always saw notable drop in performance (see complex benchmark)

[borodean]

True. Updated in a way that is still shorter, but preserves the original logic: 000f178.

[borodean]

I reverted two other commits that were altering the API. Size breakdown as of now:

Size: 2598 B
Size after GZip: 735 B
Savings: −46 B
Savings after GZip: −6 B

[ai]

If we are going this way, should we change Prettier settings to reduce ( and ) for single argument function?

[borodean]

That makes sense if we're all-in on squeezing every byte out of it: ed55367.

[ai]

Honestly, we are in overkill zone 😅

But why not? I truly enjoyed my byte-for-byte war in Nano ID (when it doesn’t hit users).

Just note, that gzip size it not relevant for Node.js libraries. We are using gzip size for browser tools.

[borodean]

that gzip size it not relevant for Node.js libraries

NPM downloads archived packages, doesn't it? So measuring size after GZip is a way to estimate the achievability of the package.

[borodean]

Honestly, we are in overkill zone

To be honest, I'm on board with Sindre Sorhus and the likes that the whole fuss is overkill.

[ai]

NPM downloads archived packages, doesn't it? So measuring size after GZip is a way to estimate the achievability of the package.

It is totally impossible to use it as selling point 😅.

It is even hard to ask people to think about node_modules size.

[ai]

To be honest, I'm on board with Sindre Sorhus and the likes that the whole fuss is overkill.

Just check out your node_modules. You will find that around 50% of content is just useless (development configs, huge dependencies for one small function, etc).

If you have 10 projects on your laptop, 5 GB will be lost for nothing.

It is so strange how people like to make jokes about node_modules size, but ignore to promote node_modules size care. We are to care about a problem only when we can make fun, not when we need to do something.

[alexeyraspopov]

@borodean, could you please rebase the branch so we can run the CI against it? Just to be safe and check init time benchmark changes?

[borodean]

could you please rebase the branch

Rebased and pushed.