0.33.3 Throws TypeError: A string was expected
#4095
Comments
|
Nothing in the stack trace provided here is from within sharp itself. If you still require help you'll need to provide some sample code that allows someone else to reproduce or at least better understand how you're trying to use sharp. |
|
Thanks for a quick response. Yeah, I know, it's minimized code (sorry). Sadly I can't get full trace from our deployed instance. All calls to The exception happens right here (I've added some logs right before & after the code above to be sure) Nothing fancy. As I mentioned, it works perfectly fine locally, and in Azure on version Really not sure what's going on and I'm fine with staying on older version, but figured I could post it here just in case others encounter(ed) same issue. |
My best guess would be that logic in your bundling step is erroneously polyfilling (i.e. monkey-patching) something fundamental, perhaps Please can you try 0.33.1 and 0.33.2 to help narrow this down. |
|
I don't think the bundling should be a problem here as it works with older versions. It's an Angular 17 SSR app (just FYI). This code is executed strictly on server (Node 20 - LTS on Linux). I did several new releases one by one:
The only changes between these releases are |
My best guess remains that something is being polyfilled in an unexpected or broken way. Can you prevent Angular from generating polyfills for the server side code? If not, what objects and functions are being polyfilled by Looking at the changes to sharp between v0.33.2 and v0.33.3 there is 7bc74fe that introduces the use of |
|
Getting the same error on my apollo server.
both variables are paths /srv/http/blabla.jpg etc
|
|
Please can you create a standalone repo with minimal dependencies that allows someone else to reproduce. |
Yes i will try to do that! I'm not that experienced in repos. Do i do that on github or some pastebin variant? |
Yes please, that would be ideal, I'd expect to see a |
Sorry for late reply. I was working on the minimal repo but didnt mange to get the error. Then i saw that i now used 0.33.4. And the problem seems to be gone? So no need to work any more on it? :) |
|
@Enngage Were you able to make any progress with this? |
|
Hey @lovell, I've tried upgrading to |
|
Thanks for the update.
When you say "simplest example", is this with sharp as the only dependency, or are you still using Angular and therefore at the mercy of its Sadly, without a complete, minimal repo declaring the dependencies, code and build steps that will allow someone else to reproduce, there's not a lot anyone can do to help. |
|
Maybe my started working with 34 is because I upgraded to node 22 aswell ? |
|
@Enngage Were you able to make any progress with this, e.g. providing a minimal repo that allows someone else to reproduce? |
|
Had the same problem (node 20) in my case it helped to update to node 22. |
|
All the signs here point to an Angular-provided server-side polyfill that is incompatible with Node.js 20 and that you're seeing the effects of this via sharp. I'll close this for now, but please feel free to re-open with a minimal set of code/dependencies that allows someone else to reproduce. |
|
I'm not able to provide a reproduce repo right now, but I just want to mention for any future stumblers that we started having this problem with NextJS and Node 20 with |
|
I've been getting the same error since upgrading to v0.33.5, downgrading to v0.33.4 resolves the issue. Details:
The errors are occurring in a test suite executed with tsx and ava. No intentional polyfills, but it's possible something else is happening internally. I've so far been unable to create a simple reproduction, other than cloning https://github.com/donmccurdy/glTF-Transform and running... yarn && yarn dist
npx ava packages/functions/test/texture-compress.test.ts --no-worker-threads... but I realize it's a large project and not a good minimal example, I'll post a better example if I can figure out how... so far my simpler tests have not recreated the issue. |
|
@donmccurdy Thanks for the extra info, I can't reproduce locally but I do notice your monorepo has the potential for multiple versions of sharp to be involved: I wonder if the wrong binary is sometimes being selected at I tried upgrading only the |
|
Hello, I encountered the same issue with Code snippet: Docker file error: I fixed it by downgrading to |
|
I think this might relate to having 2 different patch versions of sharp in the same installation tree where they depend on 2 different patch versions of libvips. I've opened libvips/libvips#4141 to discuss possible solutions. |
|
Thanks @lovell! I quickly tried A different but related possibility would be that Sharp or a dependency uses both CJS and ESM exports, and we get duplicate copies of a dependency from the same version ('dual package hazard') ... not sure if that could cause similar issues. |
Based on the stack traces above, both appear to be from v0.33.4 (or earlier), as line 1534 in v0.33.5 is a comment. See: Line 1534 in 19d0e27 Line 1534 in fc32e0b |
|
Could someone provide a standalone reproducer for this? I have tried this to no avail: $ git clone https://github.com/donmccurdy/glTF-Transform.git
$ cd glTF-Transform/
$ git checkout a52dfc6804a03a3e2c11e24802896f08126853bf~1
HEAD is now at bdbecdd5 chore(deps): update devdependencies (non-major) (#1494)
$ sudo corepack enable
$ yarn && yarn dist
[...]
Lerna (powered by Nx) Successfully ran target dist for 7 projects (16s)
$ npx ava packages/functions/test/texture-compress.test.ts --no-worker-threads
✔ unknown format
✔ size increase
✔ original formats
✔ jpeg
✔ png
✔ webp
✔ incompatible format
✔ excluded slots
✔ jpeg / jpg
✔ resize - sharp
✔ fallback to ndarray-pixels
✔ resize - ndarray-pixels
─
12 tests passed
$ yarn why sharp
├─ @gltf-transform/cli@workspace:packages/cli
│ └─ sharp@npm:0.33.5 (via npm:~0.33.4)
│
└─ ndarray-pixels@npm:4.1.0
└─ sharp@npm:0.33.5 (via npm:^0.33.4) |
|
I was also unable to reproduce this issue using Details$ mkdir sharp-test
$ cd sharp-test
$ npm init -y
$ npm install sharp@0.33.5
$ npm why @img/sharp-libvips-linux-x64
node_modules/@img/sharp-libvips-linux-x64
optional @img/sharp-libvips-linux-x64@"1.0.4" from @img/sharp-linux-x64@0.33.5
node_modules/@img/sharp-linux-x64
optional @img/sharp-linux-x64@"0.33.5" from sharp@0.33.5
node_modules/sharp
sharp@"^0.33.5" from the root project
optional @img/sharp-libvips-linux-x64@"1.0.4" from sharp@0.33.5
node_modules/sharp
sharp@"^0.33.5" from the root project
$ node -e "require('sharp')({text: { text: 'test' }}).toFile('x.png')"
$ mkdir subdir
$ cp x.png subdir/
$ cd subdir
$ npm init -y
$ npm install sharp@0.33.4
$ npm why @img/sharp-libvips-linux-x64
node_modules/@img/sharp-libvips-linux-x64
optional @img/sharp-libvips-linux-x64@"1.0.2" from @img/sharp-linux-x64@0.33.4
node_modules/@img/sharp-linux-x64
optional @img/sharp-linux-x64@"0.33.4" from sharp@0.33.4
node_modules/sharp
sharp@"^0.33.4" from the root project
optional @img/sharp-libvips-linux-x64@"1.0.2" from sharp@0.33.4
node_modules/sharp
sharp@"^0.33.4" from the root project
$ LD_PRELOAD=../node_modules/@img/sharp-libvips-linux-x64/lib/libvips-cpp.so.42 node -p "require('sharp')('x.png').toFile('out.png')"
Promise {
{
format: 'png',
width: 22,
height: 9,
channels: 3,
premultiplied: false,
size: 390
}
}
$ LD_DEBUG=bindings LD_PRELOAD=../node_modules/@img/sharp-libvips-linux-x64/lib/libvips-cpp.so.42 node -e "require('sharp')('x.png').toFile('out.png')" 2>&1 | grep "calling fini: .*libvips-cpp.so.42"
10159: calling fini: ../node_modules/@img/sharp-libvips-linux-x64/lib/libvips-cpp.so.42 [0]
$ cd ../
$ LD_PRELOAD=subdir/node_modules/@img/sharp-libvips-linux-x64/lib/libvips-cpp.so.42 node -p "require('sharp')('x.png').toFile('out.png')"
Promise {
{
format: 'png',
width: 22,
height: 9,
channels: 3,
premultiplied: false,
size: 390
}
}
$ LD_DEBUG=bindings LD_PRELOAD=subdir/node_modules/@img/sharp-libvips-linux-x64/lib/libvips-cpp.so.42 node -e "require('sharp')('x.png').toFile('out.png')" 2>&1 | grep "calling fini: .*libvips-cpp.so.42"
10227: calling fini: subdir/node_modules/@img/sharp-libvips-linux-x64/lib/libvips-cpp.so.42 [0]It would be great if someone could verify this on macOS. Replace |
|
I could reproduce this by applying this patch: --- a/lib/output.js
+++ b/lib/output.js
@@ -159,7 +159,7 @@ function toBuffer (options, callback) {
} else if (this.options.resolveWithObject) {
this.options.resolveWithObject = false;
}
- this.options.fileOut = '';
+ this.options.fileOut = undefined;
const stack = Error();
return this._pipeline(is.fn(options) ? options : callback, stack);
}$ node -e "require('sharp')('x.png').toBuffer()"
/home/kleisauke/sharp-test/node_modules/sharp/lib/output.js:1536
sharp.pipeline(this.options, (err, data, info) => {
^
TypeError: A string was expected
at /home/kleisauke/sharp-test/node_modules/sharp/lib/output.js:1536:15
at new Promise (<anonymous>)
at Sharp._pipeline (/home/kleisauke/sharp-test/node_modules/sharp/lib/output.js:1535:14)
at Sharp.toBuffer (/home/kleisauke/sharp-test/node_modules/sharp/lib/output.js:164:15)
at [eval]:1:27
at runScriptInThisContext (node:internal/vm:209:10)
at node:internal/process/execution:118:14
at [eval]-wrapper:6:24
at runScript (node:internal/process/execution:101:62)
at evalScript (node:internal/process/execution:136:3)
Node.js v22.9.0So, this sounds like a bundling/minification issue. |
|
I can't reproduce the exact problem, but here's a way to "force" a version mismatch that someone else might be able to build upon.
{
"dependencies": {
"fast-average-color-node": "3.1.0",
"sharp": "0.33.4"
}
}
require("fast-average-color-node");
const sharp = require("sharp");
console.log(sharp.versions.vips);
console.log(require("@img/sharp-linux-x64/sharp.node").libvipsVersion());Running Running This demonstrates sharp v0.33.4 using libvips v8.15.3 from inside the fast-average-color-node dependency instead of its own v8.15.2 (due, I think, to the |
|
I think it matches on filename rather than the $ LD_DEBUG=libs node index 2>&1 | grep "libvips-cpp.so.42"
9746: find library=libvips-cpp.so.42 [0]; searching
9746: trying file=/redacted/node_modules/fast-average-color-node/node_modules/@img/sharp-linux-x64/lib/../../sharp-libvips-linux-x64/lib/glibc-hwcaps/x86-64-v4/libvips-cpp.so.42
9746: trying file=/redacted/node_modules/fast-average-color-node/node_modules/@img/sharp-linux-x64/lib/../../sharp-libvips-linux-x64/lib/glibc-hwcaps/x86-64-v3/libvips-cpp.so.42
9746: trying file=/redacted/node_modules/fast-average-color-node/node_modules/@img/sharp-linux-x64/lib/../../sharp-libvips-linux-x64/lib/glibc-hwcaps/x86-64-v2/libvips-cpp.so.42
9746: trying file=/redacted/node_modules/fast-average-color-node/node_modules/@img/sharp-linux-x64/lib/../../sharp-libvips-linux-x64/lib/libvips-cpp.so.42
9746: calling init: /redacted/node_modules/fast-average-color-node/node_modules/@img/sharp-linux-x64/lib/../../sharp-libvips-linux-x64/lib/libvips-cpp.so.42
9746: calling fini: /redacted/node_modules/fast-average-color-node/node_modules/@img/sharp-linux-x64/lib/../../sharp-libvips-linux-x64/lib/libvips-cpp.so.42 [0]Since I recently started distributing the On Windows, a similar approach is followed: On macOS, it assigns a unique install name id within the Python namespace: I think sharp could implement a similar approach to avoid libvips version mismatches, though this would mean potentially having two instances of libvips running in the same process. |
|
Oh, I just noticed this for macOS:
libvips increases the compatibility version only for minor versions, not for patch versions, see: |
Possible bug
Locally everything works fine, but our deployment in Azure (Node 20 LTS, linux) started throwing exceptions such as:
Everything works perfectly fine with
0.33.0. The dependency version change is the only difference in deployments. It works perfectly fine locally even with latest version0.33.0.Not sure if I can provide more information since it's a bit unfortunate error and only reproducable within Azure.
The text was updated successfully, but these errors were encountered: