This PR makes `waitUntil` consistent when interacting with it via `vc
dev`. That includes:
**be possible to call `waitUntil` from the context second argument in
web handlers functions (Node.js & Edge)**:
```js
export function GET(request, { waitUntil }) {
waitUntil(fetch('https://vercel.com'));
return new Response('OK');
}
```
**be possible to call `waitUntil` imported from `@vercel/functions`**
(Node.js & Edge):
```js
import { waitUntil } from '@vercel/functions';
export function GET(request) {
waitUntil(fetch('https://vercel.com'));
return new Response('OK');
}
```
Additionally, `@vercel/functions` can be adopted for other framework to
take advantage of this pattern at Vercel.
---------
Co-authored-by: Javi Velasco <javier.velasco86@gmail.com>
Undoes #10980 (mostly). This appears to be some kind of caching issue. Works locally until you run `eslint` without `--cache` and then it will reproduce. Hopefully this is the last time and we're not playing whack-a-mole with these pragmas every day?
Say you have a middleware (`middleware.js`) that looks like this:
```js
export async default function middleware(req, ctx) {
ctx.waitUntil(tooLongFunction())
}
async function tooLongFunction() {
console.log('tooLongFunction started')
await new Promise((resolve) => setTimeout(resolve, 10000))
console.log('tooLongFunction finished')
}
```
When you run this middleware locally with `vercel dev`, you won't see the `tooLongFunction finished` message because the server process is killed right after finishing the response. While Edge Runtime's `server.close()`, which awaits all `waitUntil` promises, is called, but `exit-hook`'s callback in CLI doesn't wait for the `close` promise to resolve.
This PR fixes this by allowing an optional graceful shutdown callback instead of killing the process immediately.
This PR disabled `node-fetch` default compression handling when the
response is not streamed.
The default behavior in node-fetch is to handle the compression. That's
great if you interact with node-fetch as user, but bad if you use it as
intermediate proxy server, since it's creating a mismatching related
with the body format and length expectations.
Instead, we disable compression, get the buffered response and compress
it again if needed.
---------
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
This PR exposes `WebSocket` to be used for Edge Runtime for `vc dev`.
Ideally, that's a thing we should to handle inside `edge-runtime`
dependency.
Unfortunately, that is not as easy as it sounds, since Edge Runtime is
doing a heavy use of vm module and `undici` is using some Node.js APIs
that are not available, or they are hard to make them working inside vm.
Related PR: https://github.com/vercel/edge-runtime/pull/309
While we're finishing that work, in order to don't delay users to start
using `WebSocket`, we can simply expose it directly from `undici` as
dependency.
---------
Co-authored-by: Chris Barber <chris.barber@vercel.com>
