Dependency on buffer package for @deepkit/type: is it necessary?

[jacoscaz]

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.

[jacoscaz]

Additionally, as of the time of writing this the last publish date for buffer goes back to 5 years ago. That is a long time. There's a bunch of clearly active issues and PRs related to dependencies and using native functions in https://github.com/feross/buffer, though.

[marcj]

I think we should remove buffer dependency. I wanted to do this for a long time now.