chore: upgrade sharp to 0.35.2

[lovell]

Extends the sharp "special case" with additional ESM/CJS-specific paths added in v0.35.0.

No longer requires the "special case" from 0.35.2 onwards.

• feat: esm lovell/sharp#4509
• Improve discovery of nested binary dependencies for code bundlers, including vercel/nft lovell/sharp#4543

The existing path check remains to support older versions and future-proof for when we switch to ESM-only.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​sharp@​0.35.2-rc.2

View full report

[styfle]

@lovell I wouldn't expect the special case to be required now that sharp fixed the logic to be statically analyzable here:

• Use static require paths for prebuilt binaries to aid dundling with Webpack lovell/sharp#4380 (comment)

I think we should figure out the failure mode instead of changing the special case (the special case should just be for old versions of sharp)

[lovell]

The prebuilt sharp packages e.g. @img/sharp-linux-x64 are now correctly discovered, however the prebuilt libvips packages e.g. @img/sharp-libvips-linux-x64 are not.

For a file to be considered necessary, is it enough to reference that file in the exports of a package.json file or does it have to be part of a require or import statement in code?

[styfle]

Typically it needs to be part of a require() or import or readFile() to be statically analyzed and emitted, but there is a bit more nuance.

For example this sharedLibEmit() does some magic that might be relevant here:

nft/src/utils/sharedlib-emit.ts

Line 20 in 7e43ba4

export async function sharedLibEmit(p: string, job: Job) {

[styfle]

I had claude try a few different solutions and they were pretty verbose since it tried to parse the .node binary to find the dependencies.

One of the solutions was much more simple seen here:

• fix: emit libvips shared library for sharp@0.35 #595

However, it feels relatively similar to the special case we already have for sharp here (checking package.json for optionalDependencies), so I'm thinking we might as well merge your PR since its less risk.

[styfle]

Lets rever this to the old version so we still have coverage for the old version

[lovell]

How about a possible alternative where the @img/sharp-libvips-* packages (for macOS and Linux) export an empty/stub .node file to make the dependency a bit more concrete?

For example, the logic in @img/sharp-linux-x64 could be modified to include something like:

try { require('@img/sharp-libvips-linux-x64/empty.node') } catch {}

This might be enough for the existing sharedLibEmit logic to then discover the other shared libraries, assuming require errors are ignored.

[styfle]

@lovell Yes that would be great!

[lovell]

I've published a release candidate v0.35.2-rc.2 of sharp with the stub.node approach and it appears to work with the existing sharedLibEmit logic and doesn't require the special case handling.

Marking this PR as draft for now until after v0.35.2 is released and the 2-day new package cool-down has passed.

I note the logic in TurboPack is slightly different from the logic in this package as it only has an ends_with check rather than a more comprehensive regex. I don't think this will work with common filenames like shared.so.1.2.3.

nft/src/utils/sharedlib-emit.ts

Line 16 in 8673d63

sharedlibGlob = '/**/*.so?(.*)';

https://github.com/vercel/next.js/blob/c5a826f59d9385363774c292d420bdfb54f02ec2/turbopack/crates/turbopack-resolve/src/node_native_binding.rs#L147