Confirmed!
Works in Windows now!

(I spent a total of $5 on GCP for a Windows machine 😢)

Working on the Windows support for the deno_node PipeWrap .

Help Wanted

I encountered an issue when working on the node compat:

import * as net from 'node:net'

// I have a server listening on this pipe
// ```ts
// const pipe = Deno.pipe.listen({ path: "\\\\.\\pipe\\mypipe1", kind: "windows", pipeMode: "byte" })
// const ab = new Uint8Array(32)
// await pipe.read(ab); // didn't resolve, it resolve to null after the other side closed :skull: 
// ```
const conn = new net.createConnection({ path: "\\\\.\\pipe\\mypipe1" }) 
conn.write("something") // `true`, but do nothing

// if you await here, it will stuck here
/*await */ Deno[Deno.internal].core.write(
  /* 
  If you createConnection immediately after start, 
  the pipe resource should be assigned a rid of 3
  */ 
  3, 
  new TextEncoder().encode("test")
)

I tried to write it directly via Resource Id, but the promise never resolves,
instead, it rejects after the resource closed 😢

The read still works tho, no idea why.

The Problem Only Appear In Windows (Because the issue aim to support node:net.createConnection when using Windows with named pipe)

Node compat is kinda broken still, but I wonder if the Deno.pipe API is okay?

Is this Deno.pipe namespace aligned with the rest of Deno APIs? I think we usually express this kind of variation as transport option of Deno.connect. Deno.pipe namespace looks like random deviation from the existing API design to me.

Is this Deno.pipe namespace aligned with the rest of Deno APIs? I think we usually express this kind of variation as transport option of Deno.connect. Deno.pipe namespace looks like random deviation from the existing API design to me.

TL;DR Overloading the existing API would be a mess, and complicated, so I decided to create a seperate Deno.pipe for this.

No, at the beginning. I considered just make this a transport of Deno.connect and Deno.listen

But, after considering difference between platforms:

How it works

• windows: more like unix domain socket, allow undirectional or bidirectional, there is also a pipe_mode that allow specify either message (datagram) or byte (stream)
• unix: just a directional pipe

Extra work needed

• windows: you need to explicit do a Connect, to accept one client (in tokio, it's a async fn)
• unix: no need of accept

Similarly
but differ from other deno_net APIs

Both windows and unix don't have things like accept, reusing existing Conn class is going to be hard

So
Overloading the existing API would be a mess, and complicated, so I decided to create a seperate Deno.pipe for this.

Ok. Thanks for the clarification

This PR currently fixes compatibility with the following packages:

• node-notifyer

The following packages still do not work properly:

• discord-rpc
• node-pty

yeah, somehow after put Deno.pipe to PipeWrap,it stopped accepting writes, so these packages is still broken, node-notifier somehow doesn't require bidirectional communication so it's fine

This PR currently fixes compatibility with the following packages:

• node-notifyer

The following packages still do not work properly:

• discord-rpc
• node-pty

node-pty relies on node:fs.open pipe directly, which somehow broken when opening pipe, i guess it's better to do that follow up, not in this PR.

we still needs fs.* stuff's pipe support, but I guess this pr is already able to marge :)

• discord-rpc: needs fs.existsSync's pipe support
• node-pty: needs fs.openSync's pipe support

Guess it would be better to move PipeWrap to the Rust side

#31624

I think it should be a Deno API for named pipes for all platforms tho, but anyways