feat: update to deno v2

[ohroy]

summary

• change Deno.Writer / Reader / Closer and its sync type to std Remove pure JS (non native) io functions from Deno namespace denoland/deno#9795
• rework BufReader to buf.read BREAKING(io): remove BufReader denoland/std#6056
• use deno.json
• fix jsr:@std/io v0.225 Breaking change #47

[langpavel]

This is probably the thing I'm waiting for:

SyntaxError: The requested module 'jsr:@std/io' does not provide an export named 'BufReader' at https://deno.land/x/[email protected]/deps.ts:1:18
... {
  code: "ERR_MODULE_NOT_FOUND"
}

[lenkan]

Thanks! I forgot to mention that I ran the workflow last week but it failed. I think it just needs to be updated to use deno v2.

[bramtechs]

I've updated the workflow in my PR ohroy#1 to use Deno v2. I don't really know how making a PR for another PR works on Github, but consider taking a look, @ohroy.

[ohroy]

@bramtechs Thank you for perfecting it ! I've merge it to my branch, now this should auto sync changes. let's wait @lenkan check it

[lenkan]

Thanks a lot!

In general, it looks good to me! However, it would be good to make sure there is test coverage for the case when the connection reader does not read the entire buffer in a single call. I think it might cause issues (?). That was the reason the BufReader was used previously.

[lenkan]

I am wondering if this might cause issues on slower connections. From the docs https://docs.deno.com/api/deno/~/Deno.Conn#call_signature_read_0:

It is possible for a read to successfully return with 0 bytes. This does not indicate EOF.
It is not guaranteed that the full buffer will be read in a single call.

These are the cases that BufReader handled. I see the tests passes though. But I do not remember if there is a test that specifically triggers the case where the full buffer is not read in a single call.