Consider alternative color parsing library

[mrginglymus]

ref: #4449, e18e/ecosystem-issues#203

Sharp currently depends on color@^4.2.3. This package depends transitively on simple-swizzle, a library which has been recommended against being used by the author for at least three years, and was recently compromised.

Whilst color@^5.0.0 has removed its transitive dependence on simple-swizzle, it has also gone esm only, which is incompatible with the supported node versions of this library.

For completeness then, there are three options I can see:

1. do nothing - none of the packages are currently vulnerable, and all will continue to work. However, there is a reasonable chance that simple-swizzle will be marked as deprecated, which may trigger warnings for downstream users
2. update minimum supported version of node, update to color@^5.0.0. As mentioned earlier, this is not acceptable
3. update to a new color parsing library that does not pull in so many dependencies, and still supports cjs.

The hardest part of 3. will be finding which of the hundreds of color parsing libraries out there is best fit ;)

[lovell]

Thanks for the detailed suggestion, I think the best approach right now is to vendor/fork/re-publish the non-ESM version of color and clean it up there, perhaps under the @img organisation, and more importantly with the correct spelling of colour 😜

[styfle]

Are you gonna vendor all its transitive dependencies too?

Also note that you can await import('some-esm-pkg') from CJS so you can support old versions of Node.js but you would need to switch a few functions from sync to async.

[outslept]

My initial suggestion was to try colord - https://www.npmjs.com/package/colord. A bit bigger in size. But the problem is it might miss some of the features color provided.

[mrginglymus]

It also has a different shape for RGBA which breaks its parsing; it expects a for alpha channel where sharp provides alpha :(

[lovell]

I did a quick code review of colord and its regexes to parse colour strings have got ReDoS attack written all over them so I think we'd need to release a patched version anyway given the maintainers don't appear to be active.

https://github.com/omgovich/colord/blob/3f859e03b0ca622eb15480f611371a0f15c9427f/src/colorModels/cmykString.ts#L4

[mrginglymus]

The regexes in color-string don't look much friendlier...
https://github.com/Qix-/color-string/blob/d9b04bb2989b2279079ed1b48ac2e9d61291ef64/index.js#L53

Thought perhaps that's just another argument for vendoring.

[lovell]

I've published an @img/colour package to provide a CommonJS interface of the latest color package.

The next version of sharp will switch to use this as a dependency instead of color until the earliest minimum supported version of Node.js that is not fully ESM compliant reaches end-of-life, which will be approximately April 2027 according to the current Node.js release schedule.

[43081j]

@lovell on the EOL stuff - remember that all LTS versions of node can require an ES module now

so this should mean you don't need to wait until the April 2027 date to bump the minimum version?

i.e. sharp can still support CJS consumers as long as they are on node 20 and above since they can require("sharp") even if sharp goes ESM only

or am i missing something? (very possible 😅 )

EDIT:

ah i see, you're waiting until one of these versions reaches EOL! i misunderstood 👍

[lovell]

v0.34.4 now available with the latest color as a dependency via the CommonJS wrapper of @img/colour, which also adds the benefit of being able to use package provenance.

(Approximately half of all the color package's ~34 million downloads per week are due to it being a dependency of sharp.)