Issue 1:
This has long been missing from JS/TS environments: the ability to easily serialize and reify a function, along with its contextual dependencies. I see this being useful to enable colocation of code intended for execution in different environments. This will be useful to the creation of experiences that blend build time, server side, and frontend code.

Take the NextJS 9.3 experience, for instance:

import {getDynamicValue} from "./somewhere";
// we DO NOT want this import to appear in the frontend code
import {sensitiveFn} from "./sensitive-module";

// gather some values, on which our fns will depend
const GREETING_ENDING = await getDynamicValue();
const USED_IN_BOTH_ENVIRONMENTS = await getDynamicValue();

// export fn for the serverless environment
export const getServerSideProps = () => {
sensitiveFn();
console.log(USED_IN_BOTH_ENVIRONMENTS);
return {
name: "Deno",
}
}

// export the front-end component
export default (props: {name: string}) => {
console.log(USED_IN_BOTH_ENVIRONMENTS);
return (
<div>
Hello {props.name}{GREETING_ENDING}
</div>
)
}

While this example doesn't perfectly-illustrate NextJS constraints (the top-level awaiting of dynamic values), it conveys the use case nonetheless: the build process is responsible for extracting the page component (default), along with a serverless pre-rendering handler (getServerSideProps). These functions make use of in-scope variables, some of which cannot be statically analyzed. I believe it will become increasingly important to have a standard approach to capturing any given function. Let's also take a look at the serverless use case:

In the aws-cdk, users describe their infrastructure separately from the runtime code that executes on that infrastructure:

const getOneLambda = new lambda.Function(this, 'getOneItemFunction', {
code: new lambda.AssetCode('src'),
handler: 'get-one.handler',
runtime: lambda.Runtime.NODEJS_10_X,
environment: {
TABLE_NAME: dynamoTable.tableName,
PRIMARY_KEY: 'itemId'
}
});

If there were a seamless mechanism to serialize a function, one could enable the following DX:

import * as getOne from "./src/get-one";

const getOneLambda = new lambda.Function(this, 'getOneItemFunction', getOne.handler);

The location of the code and handler are no longer necessary, the runtime is inferred as the currently-executing runtime, and the environment variables can be directly referenced from within the Lamdba handler.

Here's Pulumi's approach to this problem. They're using V8 stack tracing and the TypeScript compiler at runtime.

Apologies that I cannot offer any suggestions as to how the ideal implementation looks. Not sure if it lays in Rusty V8 and Deno core, or if this would better-exist as a 3rd-party library. Nevertheless, I hope you'll consider this feature request, as I do believe it paves the way for much better experiences in many domains.

Thank you for your consideration.

Issue 2:
Hi, I'm trying out the unstable Deno.upgradeWebSocket and encountered an issue accepting a WebSocket from Firefox.

Firefox is sending this connection: "keep-alive, Upgrade" header when connecting to a websocket. That causes throw here

function upgradeWebSocket(request, options = {}) {

// ...

if (request.headers.get("connection")?.toLowerCase() !== "upgrade") {
throw new TypeError(
"Invalid Header: 'connection' header must be 'Upgrade'",
);
}

// ...

while the current std logic for accepting sockets doesn't care about the connection header at all.

export function acceptable(req: { headers: Headers }): boolean {
const upgrade = req.headers.get("upgrade");
if (!upgrade || upgrade.toLowerCase() !== "websocket") {
return false;
}
const secKey = req.headers.get("sec-websocket-key");
return (
req.headers.has("sec-websocket-key") &&
typeof secKey === "string" &&
secKey.length > 0
);
}