Initial Implementation

[maxmcd]

No description provided.

[tmcw]

There are both TypeScript and JavaScript versions of private properties - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_properties - TypeScript's are just forbidding your own code from accessing the "private" variable whereas JavaScript's make it really private - probably we should prefer JavaScript private.

[maxmcd]

@tmcw requesting re-review on this one.

A note on a change since your last review:
After the initial version and Andre's comment about security on the listener I tried to find a way to ensure that the Deno server could be connected to by the host, but then would not serve requests to someone else trying to connect.

Deno actually makes this pretty easy. You can do the following and only accept a single connection:

const server = Deno.listen({
  hostname: "0.0.0.0",
  port: 0,
});

// Accept the first connection and serve HTTP.
const conn = await server.accept();
const httpConn = Deno.serveHttp(conn);
for await (const requestEvent of httpConn) {
  // Handle the HTTP request event.
}

// Close the server to reject all future connections.
server.close();

The issue here is that using the Deno.serveHttp prints a deprecation notice because it is planned for removal. I've asked about alternatives, but it seems there's no way to do this with non-deprecated APIs at the moment.

This would not be a big deal, but Deno prints a warning in the logs:

warning: Use of deprecated "Deno.serveHttp()" API. This API will be removed in Deno 2. Run again with DENO_VERBOSE_WARNINGS=1 to get more details.

This can be disabled with --quiet, but that would disable all warnings that might be helpful for users.

I guess we could clean it from the logs ourself. I'm going to explore using unix sockets as an alternative because it might skip this issue and provide additional security, but fyi this is the state of the lib for now.

[tmcw]

I will read the rest of this in a bit, but pushing comments now just to keep the ball rolling

[tmcw]

We'd still have a guest.ts or similar, right, because we have different rules for exports there - the first import is taken and it doesn't have to be default.

[maxmcd]

Ok yes, I was going to ask you about this. Correct we'd still have guest.ts. I just wrote up something that worked, but wasn't sure what might be best here. I'll extend it to support the first export as well? Or just leave it as-is because at this layer it's just whatever works for us?