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.3

View full report

@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)

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?

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:

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.

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.

@lovell Yes that would be great!

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.

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

I spoke to the @mischnic on the turbopack team we think require('pkg/stub.node') is probably going to be prone to error.

If you know the exact files that need to be included, you could instead do path.join(__dirname, 'file.so'), path.join(__dirname, 'header.h')`, etc for the files you expect to be included.

You can test this locally without needing to publish a new version by using

npm i -g @vercel/nft
echo "require('path/to/sharp')" => example.cjs
nft print example.cjs

I've now updated this PR to the latest sharp v0.35.3, which removes the stub and instead uses require.resolve to ensure the shared library binary is included in the list of files to include.

For example, the index.cjs file in the @img/sharp-linux-x64 package contains:

try { require.resolve('@img/sharp-libvips-linux-x64/binary'); } catch {}

...and the package.json file in the @img/sharp-libvips-linux-x64 package contains:

  "exports": {
    "./binary": "./lib/libvips-cpp.so.8.18.3"
  },

This approach works with the built-in (i.e. no special case) logic of the @vercel/nft package. Assuming require.resolve paths are traced it should also work with TurboPack and likely other bundlers.