Enhancement: support block/unblock at pipeline level (as well as process level)

[styfle]

Possible bug

The methods sharp.block() and sharp.unblock() seem to impact all instances and of all dependencies in the tree, not just the one required/imported.

In fact, it even impacts different versions of sharp on the same machine.

Is this a possible bug in a feature of sharp, unrelated to installation?

• Running npm install sharp completes without error.
• Running node -e "import 'sharp'" completes without error.

If you cannot confirm both of these, please open an installation issue instead.

Are you using the latest version of sharp?

• I am using the latest version of sharp as reported by npm view sharp dist-tags.latest.

If you cannot confirm this, please upgrade to the latest version and try again before opening an issue.

If you are using another package which depends on a version of sharp that is not the latest, please open an issue against that package instead.

What is the output of running npx envinfo --binaries --system --npmPackages=sharp --npmGlobalPackages=sharp?

  System:
    OS: macOS 26.6
    CPU: (11) arm64 Apple M3 Pro
    Memory: 253.45 MB / 36.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.23.1 - /usr/local/bin/node
    Yarn: 1.22.22 - /usr/local/bin/yarn
    npm: 12.0.2 - /usr/local/bin/npm
    pnpm: 11.18.0 - /usr/local/bin/pnpm
    bun: 1.3.14 - /opt/homebrew/bin/bun
    Deno: 2.4.1 - /opt/homebrew/bin/deno

Does this problem relate to file caching?

The default behaviour of libvips is to cache input files, which can lead to EBUSY or EPERM errors on Windows.
Use sharp.cache(false) to switch this feature off.

• Adding sharp.cache(false) does not fix this problem.

Does this problem relate to images appearing to have been rotated by 90 degrees?

Images that contain EXIF Orientation metadata are not auto-oriented. By default, EXIF metadata is removed.

• To auto-orient pixel values use the parameter-less rotate() operation.

• To retain EXIF Orientation use keepExif().

• Using rotate() or keepExif() does not fix this problem.

What are the steps to reproduce?

Create two instances of sharp, and have use default and the other block. The order you run the code matters.

What is the expected behaviour?

Should succeed regardless of the order.

Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem

function optimizeSvg() {
  const sharp = require('sharp')
  const svg = Buffer.from('<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 200 150"/>')
  return sharp(svg).png().toBuffer().then(() => console.log('svg success')).catch(() => console.error('svg FAIL'))
}

function optimizeJpg() {
  const sharp = require('sharp')
  sharp.block({ operation: ['VipsForeignLoad'] })
  sharp.unblock({ operation: ['VipsForeignLoadJpeg'] })
  const jpg = Buffer.from('/9j/2wBDAP//////////////////////////////////////////////////////////////////////////////////////wAALCAABAAEBAREA/8QAJgABAAAAAAAAAAAAAAAAAAAAAxABAAAAAAAAAAAAAAAAAAAAAP/aAAgBAQAAPwBH/9k=', 'base64')
  return sharp(jpg).png().toBuffer().then(() => console.log('jpg success')).catch(() => console.error('jpg FAIL'))
}


optimizeSvg()        // success
  .then(optimizeJpg) // success
  .then(optimizeSvg) // FAIL

Please provide sample image(s) that help explain this problem

Not needed since its inlined

[styfle]

@lovell I think the general problem here is that sharp doesn't let you instantiate a class, so its all the same instance being mutated.

But this makes it nearly impossible to use the block feature since other dependencies that you don't control may rely on that behavior being unblocked.

See related vercel/next.js#96621

One solution might be allowing blocks per request instead of global. Thoughts?

[lovell]

The libvips "block" feature, upon which this depends, works at a process level hence the behaviour you're seeing.

To add this on a per-pipeline basis would involve adding logic to sharp or perhaps modifying libvips likewise. I'll label as a future possible enhancement for now.