Color spaces are not tree-shakeable

(Remaining part of #159)

While the new procedural API is tree-shakeable wrt functions, since color spaces register themselves onto ColorSpace.registry, this means they are not tree-shakeable.

To make them tree-shakeable, we’d need to eliminate side effects from the color space modules. Then, the importing code would register them.

Something like:

import ColorSpace from "COLORJS_ROOT/src/space.js";
import oklch from "COLORJS_ROOT/src/spaces/oklch.js";
ColorSpace.register(oklch);

We could make this less painful by offering pre-generated indices that do this for all existing color spaces, but I’m still struggling with the idea of requiring more plumbing to use Color.js, which makes it easier to make mistakes. E.g. someone could easily forget to register their color space and do something like:

import oklch from "COLORJS_ROOT/src/spaces/oklch.js";
let color = new Color("oklch", [.5, .2, 340]); // TypeError: No color space found with id = "oklch"

Note that registration is needed only to use string ids instead of color space objects. The API is perfectly usable with just passing identifiers around and never registering any color space, like so:

import srgb from "COLORJS_ROOT/src/spaces/srgb.js";
import oklch from "COLORJS_ROOT/src/spaces/oklch.js";
let color = new Color(oklch, [.5, .2, 340]);
color.to(srgb);

Thoughts?

[lydell]

Sure thing! Opened a new issue: https://github.com/LeaVerou/color.js/issues/204

[LeaVerou]

Can you open a new issue then since this is closed?