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>
* Forces the AL2 build container image for fixtures that depend on it,
via `engines.node` in package.json for most cases.
* The `testDeployment()` function was updated to send
`projectSettings.nodeVersion` in the POST body, to mimic the behavior in
CLI.
* For Go, Ruby, and Python tests, the `projectSettings.nodeVersion`
property is set "globally" in the Jest setup file, so that individual
fixtures didn't need to be adjusted.
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.
In a recent undici update, setting the `host` header for fetch requests became invalid (https://github.com/nodejs/undici/pull/2322).
We relied on this in order to proxy serverless dev server requests via `@vercel/node`.
This PR replaces the usage of `undici.fetch` with `undici.request`.
It is blocked by an `undici` type change: https://github.com/nodejs/undici/pull/2373
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>
Until now, the user code response it's buffered and serialized. This is
mismatching how Vercel works these days.
This PR enables streaming response in `vc dev` for Edge/Serverless.
As part of the implementation, the `node-bridge` which spawns a process
to consume the user code is not necessary anymore.
Some necessary files (like HTTP server helpers) have been moved to live
in node builder package instead.
---------
Co-authored-by: Ethan Arrowood <ethan.arrowood@vercel.com>
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
Some unit tests didn't run since Aug 2022 because they are not included as part of the testing command.
This PR introduce `unit` and `integration` folders for testing, so anything that it's placed there will be run as part of the testing command.
Fixes this error:
```
@vercel/node:test-unit: FAIL test/dev.test.ts (14.891 s)
@vercel/node:test-unit: × runs a mjs endpoint (5057 ms)
@vercel/node:test-unit: × runs a esm typescript endpoint (5122 ms)
@vercel/node:test-unit:
@vercel/node:test-unit: ● runs a mjs endpoint
@vercel/node:test-unit:
@vercel/node:test-unit: thrown: "Exceeded timeout of 5000 ms for a test.
@vercel/node:test-unit: Use jest.setTimeout(newTimeout) to increase the timeout value, if this is a long-running test."
```
https://github.com/vercel/vercel/actions/runs/4247588973/jobs/7385801227#step:9:1039
This makes `react-dom` work as expected from within Edge Functions. Otherwise, NFT will only select the Node.js version of the files which do not work with react-dom within an Edge Function.
Follow-up to https://github.com/vercel/vercel/pull/9258, even though that issue seemed to only happen when linked to the monorepo locally. In any case, this test will ensure those log messages are intact for any other change around that part of the codebase in the future.
- Depends on https://github.com/vercel/nft/pull/297
- Fixes#7908
- Fixes#6194
This PR bumps `@vercel/nft` (for production) and `ts-node` (for
development) to fix ESM behavior.
Because Node.js cannot dynamically set [loader
hooks](https://nodejs.org/docs/latest-v18.x/api/esm.html#loaders) once a
process is started, I had to change the way `ts-node` is registered by
using environment variables such as `NODE_OPTIONS`. Most of the logic
for TS and ESM was pulled out of the child process and into the parent.
Co-authored-by: Ethan Arrowood <ethan.arrowood@vercel.com>
### 📖 What's in there?
As part of Edge function GA, we're allowing `edge` as a runtime value.
This is adding to the allowed list, so we stay backward compatible.
[Linear ticket](https://linear.app/vercel/issue/EC-481/add-edge-to-the-list-of-allowed-runtimes)
I've kept one instance of `experimental-edge` in the test fixtures to ensure we still supports it.
### 📋 Checklist
#### 🧪 Tests
- [x] The code changed/added as part of this PR has been covered with tests
- [x] All tests pass locally with `yarn test-unit`
#### Code Review
- [x] This PR has a concise title and thorough description useful to a reviewer
- [x] Issue from task tracker has a link to this PR
### Related Issues
Otherwise you are not able to write a serverless function that returns a
Promise when using the ESLint rule
[@typescript-eslint/no-misused-promises](https://typescript-eslint.io/rules/no-misused-promises/)
Following function
```typescript
const handler: VercelApiHandler = async () => {};
```
will report a `Promise-returning function provided to variable where a
void return was expected`
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### Tests
- [x] The code changed/added as part of this PR has been covered with
tests
- [x] All tests pass locally with `yarn test-unit`
#### Code Review
- [x] This PR has a concise title and thorough description useful to a
reviewer
- [ ] Issue from task tracker has a link to this PR
This PR update the tests suite to wait for Vercel CLI tarball and then use that tarball to run E2E tests.
This is valuable because it will package all the packages in this monorepo to make the tests follow more closely what will happen in production once merged.
Since the current "Find Changes" step takes about 2 minutes, we run that first (it happens concurrently with the tarball preparation). Then once we complete "Find Changes" we wait for the tarball but it will likely be ready by that point since it also takes about 2 minutes. After both of those steps, the E2E tests continue as usual but with the `VERCEL_CLI_VERSION` set to the tarball.
- Related to #7967
- Closes#8245
- Closes#8227
* [node] Add WebAssembly importing support for the @vercel/node builder
* add comment about the original source
* trim down values to only what is required for esbuild wrapping logic
* Revert "trim down values to only what is required for esbuild wrapping logic"
This reverts commit c04dacad99f25156938dccdf2f29aac6e8282564.
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
This applies the same chunking algorithm from `@vercel/static-build` tests to `@vercel/node` tests that we can run up to 5 integration tests concurrently.
The `middlewarePath` property was not correctly stripping
the root directory setting from the value, causing Middleware
to not work correctly with Root Directory.
