Skip to content

types: return more precise Buffer<ArrayBuffer> from toBuffer#4520

Open
Andarist wants to merge 1 commit intolovell:mainfrom
Andarist:tobuffer-types
Open

types: return more precise Buffer<ArrayBuffer> from toBuffer#4520
Andarist wants to merge 1 commit intolovell:mainfrom
Andarist:tobuffer-types

Conversation

@Andarist
Copy link
Copy Markdown

No description provided.

Comment on lines +172 to +176
"peerDependenciesMeta": {
"@types/node": {
"optional": true
}
},
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is kinda more compatible with strict package managers like pnpm. If you'd like to declare an explicit range for compatible @types/node then you'd have to declare the range within a regular peerDependencies declaration and, in here, the correct range would be something like:

^18.19.54 || ^20.16.10 || >=22.7.4

Those are the versions published on 2024-09-27 and they introduced this change: DefinitelyTyped/DefinitelyTyped#70694

@lovell
Copy link
Copy Markdown
Owner

lovell commented Apr 11, 2026

Hi Mateusz, thanks for the PR.

If you hadn't seen, the next 0.35.0 release of sharp will also allow output via a new toUint8Array() to complement the existing toBuffer() - see #4355

toUint8Array(): Promise<{ data: Uint8Array; info: OutputInfo }>;

My understanding is that Node.js Buffer instances allocated by native code are treated as being backed by a SharedArrayBuffer and are considered non-transferable whereas Uint8Array instances are always backed by an ArrayBuffer and are transferable (e.g. between worker threads).

I think this means that that existing toBuffer() will resolve with a Buffer<SharedArrayBuffer> - is this something you're able to check?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants