[Replacement]: `@img/colour`

[Norbiros]

Package to replace

@img/colour

Suggested replacement(s)

another package: color

Manifest type

preferred (lighter or more modern alternative package)

Rationale

@img/colour is just a port of the color package to CommonJS. It is just better to switch back to color and use ESM, which allows for better tree-shaking.

Source:

This package converts the color package and its dependencies, all of which are MIT-licensed, to CommonJS.

Availability

No response

Code example (optional)

Before:

const Color = require('@img/colour')

const red = Color('red').hex()

After:

import Color from 'color'

const red = Color('red').hex()

[43081j]

hmm we should dig into this a bit...

@img/colour was updated more recently, has fewer deps, and is smaller.

i wonder if the right move here is to ask them to go ESM-only and rework their README to no longer be just a CJS port - but rather just be the more modern alternative.

[Norbiros]

@img/colour is solely used by sharp and sharp-related projects, meaning there is a bigger chance it might get abandoned.

@img/colour is not its own library, it is built by generating cjs compatible code from color and its sub-dependencies like color-convert into a single file. It reduces portability, but at the same time reduces the final size (less readmes, less files), giving that 20kB size difference.

"build:cjs": "esbuild node_modules/color/index.js --bundle --platform=node --outfile=color.cjs"

color library has some problems like missing oklch support, but given that @img/colour is not a fork, it is just a library that rebuilds it for CommonJS, I think the migration to color is the right choice and we should continue improving that library.

[Norbiros]

There might be other alternatives like colorjs.io which is more modern (supports CSS Color 4), but it weights 13.2 MB instead of 91.5 kB, has different API and probably it's own caveats.

[43081j]

you are right 👍

ill wait for a 2nd opinion from core but i think color should be used here even though it is slightly bigger (because it isn't minified). it'll de-dupe better

[dreyfus92]

+1 for color here, agree with the direction, it is worth being clear about what @img/colour actually is, not a fork or an alternative, just an esbuild bundle of color regenerated for cjs. the size argument also cuts the other way in practice, the 20kb is mostly install size (readmes, unbundled files), and color / color-conver / color-string are already in half ecosystem's trees, so depending on color dedupes while @img/colour ships the same code again as an opaque build.

one thing the migration notes should call out: color@5 is esm-only, and the whole audience for @img/colour is cjs consumers, without it the before/after swap can be a bit misleading.

preferred type sounds right to me