feat(hono/context): add buffer returns

[askorupskyy]

Context

I needed to be able to return Buffers from my Hono app, and was not able to do so.

Resolves #3729 #3720

The author should do the following, if applicable

• Add tests
• Run tests
• bun run format:fix && bun run lint:fix to format the code
• Add TSDoc/JSDoc to document the code

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.71%. Comparing base (2ead4d8) to head (228c499).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3813   +/-   ##
=======================================
  Coverage   91.71%   91.71%           
=======================================
  Files         160      160           
  Lines       10195    10195           
  Branches     2885     2850   -35     
=======================================
  Hits         9350     9350           
  Misses        844      844           
  Partials        1        1           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[askorupskyy]

Tested this PR with the sample repo, using [email protected] – seems to be working fine

[yusukebe]

Is this import type necessary? In my environment, it does not throw an error without this.

[askorupskyy]

I added this for Deno. Deno does not have a Buffer exposed to the global scope

[yusukebe]

It is importing just types, but I think we should not use node:* modules in the core of hono. Actually, Buffer is not in Web Standards API.

[askorupskyy]

I think using node:buffer is fine here, especially as a Type. There's no way to polyfill types for specific platforms as far as I am aware (so Deno will continue to fail). In addition to that, node:buffer is either the default implementation for a lot of runtimes, such as Cloudflare Workers, Deno, etc, or is already defined as a global replicating Node.js API. I see no problem with using the type from Node, since all runtimes are pretty much using the same API as node.

This thing will not execute after TSC, so I think it's a good fix, at least for now. Better to have partial buffer support than none at all

[EdamAme-x]

It might be a good option to have a helper function to convert from node:buffer to the web standard accepted body format (For example, ReadbleStream).
If you think it is a good idea, we can change the implementation of this PR.

Of course, if you think it is overhead, I think current impl is fine.

[askorupskyy]

Let me see if i can make this work with a uint8array

[askorupskyy]

@yusukebe @EdamAme-x looks like Buffer indeed is a Node-only construct (they made it before Uint8Array was invented), so to be compliant with Web Standards I moved to Uint8Array, for which the Buffer is a superset. Added one more test and it looks like everything works

Buffer.from('') instanceof Uint8Array // true

[EdamAme-x]

This is unfolded BodyInit types.

type BodyInit = ReadableStream<any> | string | Blob | ArrayBufferView<ArrayBuffer | SharedArrayBuffer> | ArrayBuffer | FormData | URLSearchParams

If I added Uint8Array, _BodyInit was marked as extended.
So I think looks good to me.

type _BodyInit = ReadableStream<any> | string | Blob | ArrayBufferView<ArrayBuffer | 
SharedArrayBuffer> | ArrayBuffer | FormData | URLSearchParams | Uint8Array
//                                                              ^^^^^^^^^^

type isExtended = _BodyInit extends BodyInit ? true : false
//   ^^ true ^^

TypeSccript Playground

[EdamAme-x]

One thing I was wondering, is there a reason why URLSearchParams and FormData are not accepted?

TypeScript Playground

[askorupskyy]

@EdamAme-x first of all, BodyInit is what's used by ClientRequestImpl, which is part hc. That's to parse whatever input you give to hc – this is why your second example doesn't work. I don't think BodyInit matters in the context of this PR