Hello! The @deepkit/type package depends on the buffer NPM package as a userland implementation of Node's Buffer class, which brings along base64-js and ieee754 as indirect dependencies:
Considering the ever-increasing risks inherent in big dependency chains, would it not be better to simply rely on the Buffer global and leave it up to consumers of @deepkit/type to provide an implementation of it wherever the global is not available? Node, Deno and Bun already provide their own implementations, for example, which likely offer greater room for low-level optimization (I need to verify this assumption).
The only runtimes (that I can think of) in which a polyfill is needed are browsers, in which case depending on buffer as a polyfill would totally make sense. However, forcing that dependency even where native (and likely more performant) functions are available feels wrong.
Hello! The
@deepkit/typepackage depends on thebufferNPM package as a userland implementation of Node'sBufferclass, which brings alongbase64-jsandieee754as indirect dependencies:Considering the ever-increasing risks inherent in big dependency chains, would it not be better to simply rely on the
Bufferglobal and leave it up to consumers of@deepkit/typeto provide an implementation of it wherever the global is not available? Node, Deno and Bun already provide their own implementations, for example, which likely offer greater room for low-level optimization (I need to verify this assumption).The only runtimes (that I can think of) in which a polyfill is needed are browsers, in which case depending on
bufferas a polyfill would totally make sense. However, forcing that dependency even where native (and likely more performant) functions are available feels wrong.