Closed zburke closed 8 months ago
sharp@0.33.1: The engine "node" is incompatible with this module. Expected version "^18.17.0 || ^20.3.0 || >=21.0.0".
Could it be that you have two versions of sharp
in a dependency tree?
See also: https://github.com/lovell/sharp/issues/3878 https://github.com/lovell/sharp/issues/3911
The change in nodejs version requirements is related, @BlackEyeByLee, but it's not the full story:
package.json
says this runs on nodejs >= 14.0.0
, but the transitive requirement via sharp means the version here needs to match the version there: ^18.17.0 || ^20.3.0 || >=21.0.0
.0
). Changing the minimum operating requirements a module is like changing the requirements of a peer-dependency: adding a new requirement or bumping the version of an existing requirement is always a breaking change, even bumping from 1.2.3
to 1.2.4
, because it breaks the semver contract of backward compatibility.@andy128k, with favicons 7.1.5 the only version of sharp in my tree is 0.33.1:
platform-complete(snapshot)*
$ yarn why sharp
yarn why v1.22.19
[1/4] ๐ค Why do we have the module "sharp"...?
[2/4] ๐ Initialising dependency graph...
warning Resolution field "@rehooks/local-storage@2.4.4" is incompatible with requested version "@rehooks/local-storage@^2.4.5"
warning Resolution field "@rehooks/local-storage@2.4.4" is incompatible with requested version "@rehooks/local-storage@^2.4.5"
[3/4] ๐ Finding dependency...
[4/4] ๐ก Calculating file sizes...
=> Found "sharp@0.33.1"
info Reasons this module exists
- "@folio#stripes-cli#@folio#stripes-webpack#favicons" depends on it
- Hoisted from "@folio#stripes-cli#@folio#stripes-webpack#favicons#sharp"
info Disk size without dependencies: "676KB"
info Disk size with unique dependencies: "1020KB"
info Disk size with transitive dependencies: "1.21MB"
info Number of shared dependencies: 9
โจ Done in 1.66s.
@zburke Did you try what sharp's doc suggests? I mean the link in the error message. It seems you need to fiddle with your package-lock.json
(or yarn.lock
).
@andy128k, I've looked at those links briefly and will do so more thoroughly but
yarn install sharp
command or anything like it. That said, adding a direct dep on sharp does resolve our problem ๐คจ , and that's a pretty easy fix for us. I confess, this doesn't entirely make sense to me. Maybe it indicates some brittle logic in our build pipeline that no longer holds up with the new version of sharp though I don't think we are doing anything interesting/clever/stooopid WRT sharp in our build pipeline. Nonetheless, if you want to close this as "can't replicate", I will understand. I also ran into this issue with the new version via the favicons-webpack-plugin
package and, for what it's worth, upgrading to Node.js v20.10.0
fixed my build.
yarn why v1.22.19
yarn v1 has been in maintenance mode for almost 4 years. You'll need to add the --ignore-engines
flag, as the error message suggests, if you still have to use it. Please upgrade to yarn v3+ if possible.
Please see https://sharp.pixelplumbing.com/install for this information and lots more.
Thanks for weighing in here, @lovell. Again, since our dep on sharp is transitive, we can't add --ignore-engines
to our yarn add sharp
command because we are not running yarn add sharp
. Nonetheless, I understand your point, and am grateful for your guidance. The conclusion I am honing in on amounts to, "favicons v7.1.5, via its updated transitive dep on sharp v0.33.1, dropped compatibility with some old things (node v14, v16, < v18.17; npm v6, v8; yarn v1, v2) that v7.1.4 was compatible with when it used sharp v0.32.6."
That's fine, totally fine, but dropping support is a breaking change, so v7.1.5 really should have been v8.
If you are using astro, the package @divriots/jampack
also has a transitive dependency on sharp
. In the build
script, remove jampack ./dist
to remove it's usage. And remove it from the dev dependencies. Remove sharp
from the dependencies list if you have it and update astro to latest version. Don't know which fixed it but now I can deploy to vercel.
After bumping from v7.1.4 to v7.1.5 all builds now fail with the following error:
This is on MacOS 14.1.2:
Our Jenkins builds on Linux fail with a similar error: