Moves the type file out of the cli package and into its own standalone
package. utilizes `@vercel/style-guide` too for typescript config,
eslint, and prettier.
The error messages shown during `vc dev` when an Edge or Serverless functions returns a promise that ends up being rejected could be better.
Main changes:
- removed "socket hang up" error messages because they were not helpful to the user
- changed serverless function error handling to log explicitly and exit
- changed serverless function error message to include the request path
- changed edge function error message to include request path and a faked (but useful) stack trace
## Current
### In Production
**Serverless Function:** In production, for a serverless function rejected promise, you'll see this in the logs:
```
Unhandled Promise Rejection {
"errorType": "Runtime.UnhandledPromiseRejection",
"errorMessage": "Error: intentional break!",
"reason": {
"errorType": "Error",
"errorMessage": "intentional break!",
"stack": [
"Error: intentional break!",
" at handler (/var/task/api/node.js:3:9)",
" at Server.<anonymous> (/var/task/___vc/__helpers.js:813:19)",
" at Server.emit (node:events:527:28)",
" at parserOnIncoming (node:_http_server:956:12)",
" at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)"
]
},
"promise": {},
"stack": [
"Runtime.UnhandledPromiseRejection: Error: intentional break!",
" at process.<anonymous> (file:///var/runtime/index.mjs:1194:17)",
" at process.emit (node:events:539:35)",
" at process.emit (/var/task/___vc/__sourcemap_support.js:559:21)",
" at emit (node:internal/process/promises:140:20)",
" at processPromiseRejections (node:internal/process/promises:274:27)",
" at processTicksAndRejections (node:internal/process/task_queues:97:32)"
]
}
Unknown application error occurred
Runtime.Unknown
```
**Edge Function:** In production, for an edge function rejected promise, you'll see this in the logs:
```
Error: intentional break!
at (api/edge.js:10:10)
```
In both cases, in the browser, you see the "This Serverless/Edge Function has crashed." template with no error message or stack trace.
### In `vc dev`
**Serverless Function:** In `vc dev`, for a serverless function rejected promise, you'll see this in the output:
```
Unhandled rejection: Error: intentional break!
at handler (/Users/smassa/source/demo/edge-errors/api/node.js:3:9)
at Server.<anonymous> (/Users/smassa/source/vercel/vercel/packages/node-bridge/helpers.js:813:19)
at Server.emit (node:events:513:28)
at Server.emit (node:domain:489:12)
at parserOnIncoming (node:_http_server:998:12)
at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)
Error: Failed to complete request to /api/node: Error: socket hang up
```
**Edge Function:** In `vc dev`, for an edge function rejected promise, you'll see this in the output:
```
Unhandled rejection: intentional break!
Error: Failed to complete request to /api/edge: Error: socket hang up
```
## After Changes
### In `vc dev`
**Serverless Function:** In `vc dev`, for a serverless function rejected promise, you'll see this in the output:
```
Rejected Promise returned from /api/node: Error: intentional break!
at handler (/Users/smassa/source/demo/edge-errors/api/node.js:3:9)
at Server.<anonymous> (/Users/smassa/source/vercel/vercel/packages/node-bridge/helpers.js:824:19)
at Server.emit (node:events:513:28)
at Server.emit (node:domain:489:12)
at parserOnIncoming (node:_http_server:998:12)
at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)
```
**Edge Function:** In `vc dev`, for an edge function rejected promise, you'll see this in the output:
```
Rejected Promise returned from api/edge: intentional break!
at (api/edge.ts)
```
We can't show the real stack trace for Edge Functions because the bundling + VM execution mangles it. What's rendered here is a fake one, but it's still useful to the user.
If we currently showed the real stack trace for edge functions, it would look like:
```
Rejected Promise returned from api/edge: intentional break!
at edge (evalmachine.<anonymous>:35:9)
at FetchEvent.<anonymous> (evalmachine.<anonymous>:87:26)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async EdgeRuntime.dispatchFetch (evalmachine.<anonymous>:29:7)
at async Server.handler (/Users/smassa/source/vercel/vercel/node_modules/.pnpm/edge-runtime@2.0.0/node_modules/edge-runtime/src/server/create-handler.ts:46:26)
```
## Follow Up
We'll look into improving the Edge Function error stack traces later.
Remove `--forceExit` and wait for the child `vc dev` process to close
before continuing.
Listen to the `'close'` event instead of `'exit'` to ensure stdio has
been flushed and closed before continuing.
Some tests cause `vc dev` to spawn child processes that in turn spawn
nested child processes that do not exit when the parent exits, so a
`nukeProcessTree()` helper was added to ensure all spawned processes are
cleaned up. Furthermore, some of the nested child processes don't
respond well to `SIGTERM` and we need to use `SIGKILL` if `SIGTERM`
doesn't do the job.
I uncovered a larger issue exposed by removing the `--forceExit` flag.
The go builder uses `go run` to build and run the go-based serverless
function. Turns out that `go run` will build the executable, then spawn
it with a parent process id (ppid) of `1` (launchd) on macOS. This means
that the go serverless function executable is not detected as a child
process of `vc dev` and won't be cleaned up, yet has inherited `stdout`
and `stderr` keeping Jest alive. The solution is to explicitly `go
build` the serverless executable, then run it.
### 📋 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
- [ ] This PR has a concise title and thorough description useful to a
reviewer
- [ ] Issue from task tracker has a link to this PR
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
`runDevCommand()` assumes the dev command is an npm package and thus uses `npx` or `yarn run` to execute it. In the case of a Hugo-based app, there is no npm package, so we want spawn to find Hugo in the `PATH`. Then for Node-based apps, instead of `npx`, spawn should find the command since `node_modules/.bin` has been added to the `PATH`.
### Related Issues
> https://github.com/vercel/customer-issues/issues/871
Note: This PR is a recreation of https://github.com/vercel/vercel/pull/8864 because prettier changed a bunch of Hugo files, which was bloating the original PR.
### 📋 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
While working on #8742 i found some useful error checking code buried in
the CLI. This PR adds a new private package `@vercel/errors` that moves
those helpful utilities into its own package so it can be used
throughout the monorepo.
Implements request headers override in middlewares.
#### New middleware headers
- `x-middleware-override-headers`: A comma separated list of *all* request header names. Headers not listed will be deleted.
- `x-middleware-request-<name>`: A new value for the header `<name>`.
### Related Issues
- #8724: Add helper functions for non-Next.js middlewares
- https://github.com/vercel/next.js/pull/41380: Next.js' implementation
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### Tests
- [ ] The code changed/added as part of this PR has been covered with tests
- [ ] All tests pass locally with `yarn test-unit`
#### Code Review
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
### Related Issues
We introduced a new endpoint: `/env/pull/:projectId/:target?/:gitBranch?` which will return a complete list of key/value pairs (environment variables) for the proper target environment, using the same logic as we use for deployments.
This means that we don't need to fetch env variables from multiple sources (system, project, shared) and stitch them on the client anymore.
- removes unused logic for fetching & merging environment variables on the CLI client
- offloads env variables generation to the API
- new: shared env variables are now supported in vc env pull!
### 📋 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
- [x] Issue from task tracker has a link to this PR
We were doing this validation in `vercel dev` but not `vercel build`.
This PR adds `vercel.json` validation to `vercel build` too.
Note I am calling this a patch because invalid `vercel.json` was already failing when passed to the API so this allows a nice error message earlier in the process.
On Windows 10 and 11 machines, environment variables are not case sensitive. The system PATH is actually defined as `process.env.Path`, however Node.js kindly handles the case sensitivity and will automatically return the system path when specifying `process.env.PATH`.
When we clone the environment variables via `{ ...process.env }`, we lose the automatic resolving of `Path` to `PATH`. To fix this, we need to explicitly copy the `PATH`.
#### 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
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
This makes `vc dev` utilize the same Builder installing and importing logic that `vc build` uses. So now the Builders will be installed locally on a per-project basis, rather than being installed to a shared global installation directory.
Instead of replacing "127.0.0.1" in `vc dev`, replace "0.0.0.0" when rendering the URL to access the `vc dev` server.
The thought here is that the IPv6 form is replacing the catch-all host name (`::`), but the IPv4 version is only replacing the explicit "127.0.0.1" version, so there's an inconsistency.
Considering the catch-all host names are not usually intended to be routable anyways, we will fix the inconsistency by only replacing the catch-all versions instead of localhost.
Also, since Node.js will default to binding to the catch-all address when not explicitly specifying a host, this replacement will only happen in that case. If the user is explicitly specifing a host to bind to (i.e. `vc dev -l 127.0.0.1:8080` or `vc dev -l tcp://[::1]:8080`) then it makes more sense to print explicitly what the user specified.
When using a `rewrite` in middleware to a relative path that does not exist, the logic gets confused and falls back to the original path.
This was caused by two changes that, in combination, caused this behavior.
1. `prevUrl` was created to keep track of route results that point to other routes, but falls back to `req.url` (`prevUrl`'s initial value): [#4033](40e4b69267 (diff-142c93a61d03a1718eb765cd25e5f18d07a95358bb27ce5d5d4da314ee2fa286R1283-R1284))
2. `prevUrl` was reassigned when handling middleware: [#7973](ee1211416f (diff-00ef6e7b63ed4cae298afc2a8c84f49247855a2506270f748e4d3e41da97ad99R1538))
Because `prevUrl` was reset back to `req.url` after the first `phase` (null) was run, the updated `prevUrl` value from middleware was lost. This only matters if the second `phase` ("filesystem") was going to be hit.
Further confusing matters, this was partially fixed by https://github.com/vercel/vercel/pull/8457 because it either returned a proxy pass (which doesn't have this problem) or assigned `req.url` to include the `rewritePath`, which meant that later when `prevUrl` would default to `req.url`, it still had come from `rewritePath`. So, this is fixed for the absolute URL case, but not the relative path case.
Given all that, I think the fix we need is to keep `prevUrl` at its current value when it's not being updated based on the `routeResult`.
---
So, I made that change here. I added a test that exercises this specific behavior.
This change will allow the downstream Dev Command server be able to listen on either of `127.0.0.1` for IPv4 or `[::1]` for IPv6.
- Fixes#6639
- Fixes#8511
- Fixes#8121
- Closes#8512
- Closes#8384
### Related Issues
Adds configuration override support to `vc build` and `vc dev` commands.
### 📋 Checklist
<!--
Please keep your PR as a Draft until the checklist is complete
-->
#### Tests
- [ ] The code changed/added as part of this PR has been covered with tests
- [ ] All tests pass locally with `yarn test-unit`
#### Code Review
- [ ] This PR has a concise title and thorough description useful to a reviewer
- [ ] Issue from task tracker has a link to this PR
Previously `vc dev` would only set this env var for "create-react-app" Framework preset, but other frameworks do the "auto-open browser window" behavior as well, and respect this env var (Docusaurus, specifically).
So always set the `BROWSER=none` env var regardless of which framework preset is selected. Also simplifies the code since this was the only place `frameworkSlug` property was being used.
Middleware server setup wasn't logging errors the same way that dev server setup was. This meant that middleware instantiation errors (like invalid config) would cause requests to 500, but no errors to be logged to the console.
This PR updates the invalid config error, makes sure errors in this area are logged out, and adds a test for this behavior.
**It may be appropriate to fail the deploy (and crash `vc dev`) in this case instead, though. What do others think?**
---
During `vc dev` with middleware that has an invalid `config.matcher` value...
Before: You see a 500 response in the browser and no output in the terminal.
After: You see a 500 response in the browser and this output in the terminal:
```
Error! Middleware's `config.matcher` values must start with "/". Received: not-a-valid-matcher
```
---
Related Issue: https://github.com/vercel/edge-functions/issues/220
This is a semver major change to the public API for `@vercel/routing-utils` which includes the following breaking changes.
1. `getTransformedRoutes({ nowConfig })` props changed to `getTransformedRoutes(nowConfig)`
2. `type Source` renamed `type RouteWithSrc`
3. `type Handler` renamed `type RouteWithHandle`
4. `interface VercelConfig` removed
5. `type NowConfig` removed
6. `type NowRewrite` removed
7. `type NowRedirect` removed
8. `type NowHeader` removed
9. `type NowHeaderKeyValue` removed
The `@vercel/build-utils` package was meant be shared functions necessary for writing a Vercel Builder (aka Runtime).
This package has since bloated into the catch-all package for anything that wasn't a Builder.
This PR removes the bloat in favor of a new package, `@vercel/fs-detectors`. It also removes the need for `@vercel/build-utils` to have a dependency on `@vercel/frameworks`.
- Related to #7951
If there is no `api` directory, then you run `vc dev`, then you create a new function `api/some-func.js`, then this file would not be served as a new function.
This was being caused by incomplete "new file" handling logic. This PR ensures that the proper detection is done in each new file (`getVercelConfig`) that populates key properties (`apiDir`, `apiExtensions`, and extensionless `files`) for determining when a file is used to serve a request.
When edge functions error, they were showing a basic text response instead of the error template. They were also sending a 502 status code instead of a 500.
This PR makes the error handling of Edge Functions consistent with Serverless Functions when executed through `vc dev`. If we want to update the error templates themselves, we can do that in a separate PR.
**Note:** Production currently treats Edge Function errors differently from Serverless Function errors, but that's a known issue that will be resolved.
---
*I deleted the original outputs (terminal and browser screenshots) because they are out of date and added a lot of content to this page. See my latest comment for updated examples.*
Adds initial support for a root-level `middleware.js` / `middleware.ts` file in the `vercel dev` CLI command. This leverages the existing Edge Function invoking logic in `@vercel/node`'s `startDevServer()` function and applies the necessary response / rewrites / mutations to the HTTP request based on the result of the middleware invocation.
These two tests have been problematic on MacOS for a long time,
but now that we've re-introduced `@vercel/next` into this repo,
they've started to fail on Linux/Windows as well.
So the idea is to use the `devCommand` property so that
`@vercel/next` Builder doesn't get invoked at all.
Since the `devCommand` property was not yet being unit tested,
some logic in `vc build` needed to be adjusted in order to properly
shut down the dev command (via `tree-kill` module) when the
process was being stopped in order to cleanly shut down.
* [cli] Remove initial iteration of `vc build` and Plugins
The `vercel build` command is being restructured, so we'll remove it for
now so that this initial iteration isn't included as part of the stable
CLI release.
* Update packages/cli/src/commands/init/init.ts
Co-authored-by: Steven <steven@ceriously.com>
* Remove more `.output` references
* Remove unnecessary space
* Fix test
* Remove vc dev middleware tests for now
Co-authored-by: Steven <steven@ceriously.com>
* Prevent infinite recursion of vercel build and dev
* Improved text
* Improved the text further
* Add tests
* Debug test
* Add debug log
* Debug test
* debug test
* Debug test
* Fix test
* Debug tests
* Debug test
* Remove only from tests
* Add error documentation
* Improved docs
* Fix other test
* Fixed links to error docs
* Remove legacy error page
* Use nicer error links
Co-authored-by: Leo Lamprecht <leo@vercel.com>
* Fix middleware build result. Return middleware next when invalid result.
* Add a unit test that would have failed before previous commit.
* Copy next.js behavior.
* Add a test for invalid responses from middleware.
Co-authored-by: Leo Lamprecht <leo@vercel.com>
* Move loadPlugins to a utils file to be shared w/ dev server.
* Update loadCliPlugins to also return startDevServer and runDevMiddleware based plugins.
* Move plugins back to dependencies.
These can't be bundled as it interferes with plugin resolution.
* Hook up middleware plugins to dev server.
* Pass output object to loadCliPlugins instead of a logging function.
* Allow more than one runDevMiddleware defining plugins.
* Bundle esbuild w/ middleware plugin.
* Keep esbuild as an external
* Update middleware's esbuild.
* set old space size
* Revert "set old space size"
This reverts commit b579194a862949a11769e9087f01c31f2e1f3b60.
* Use --max-old-space-size for CLI unit tests
* Increase memory
* Use `run.js` to set the memory
* Make NODE_OPTIONS optional
Co-authored-by: Leo Lamprecht <leo@vercel.com>
Co-authored-by: Andy <AndyBitz@users.noreply.github.com>
Co-authored-by: Andy Bitz <artzbitz@gmail.com>
* Add initial `vercel-plugin-middleware`
* Ignore `entries.js` from ESLint
* Add `runDevMiddleware()` stub
* Add test
* Add support for "_middleware.{js,ts}" to `vercel dev` (#6880)
* Add websandbox from next.js codebase.
* Use node-fetch instead of next's polyfilled fetch.
* Handle middleware rewrites.
* Add response, headers, and request to websandbox context.
* Move websandbox dependency to middleware plugin.
* Add integration tests, update websandbox to support ts files and json imports.
* commit yarn.lock changes after rebasing
* Clean up left over console.logs, fix some tsc issues, and rebase issue.
* Fix failing test and eslint.
* Fix middleware test on windows.
* [examples] Update Vercel Next.js example template to 12.0.1 (#6905)
* Mark the Plugins as external to CLI's ncc build
* [cli] Improve tracing in vc build (#6898)
* [cli] Fix tracing for `vc build`
* Ignore object when there are no changes
* Make Next < 12 work with FS API w/ nft
* Update packages/cli/src/commands/build.ts
Co-authored-by: Nathan Rajlich <n@n8.io>
* Document how Next.js processing works in build
* [cli] Fix static assets (#6906)
* Make sure output path is .next
* Fix up require-server-files for processing
* Fix typo
* Move static
* Update static rename
Co-authored-by: Andy Bitz <artzbitz@gmail.com>
Co-authored-by: Nathan Rajlich <n@n8.io>
Co-authored-by: Andy <AndyBitz@users.noreply.github.com>
* Publish Canary
- vercel@23.1.3-canary.17
- @vercel/client@10.2.3-canary.15
- @vercel/static-config@0.0.1-canary.0
* [cli] Ignore `.env` and `.gitignore` in "vc build" (#6910)
* Publish Canary
- vercel@23.1.3-canary.18
* Pass workPath to plugins.
The new plugin architecture doesn't pass a full BuildOptions object, previous
to this commit it wasn't passing any options at all. I've added workingPath to
support running dev/build from directories other than the project root.
* Remove error state when package.json exists, but no build script
This allows vercel build to continue working for projects that are not using
frameworks, but use package.json to manage dependencies.
* Fix types, pull in middleware header fix from next.js
Next js PR w/ the header fix:
https://github.com/vercel/next.js/pull/30560
* Fix missing entries file for vc build.
* Update call signature of middleware when using vc build.
Co-authored-by: Drew Bredvick <dbredvick@gmail.com>
Co-authored-by: Nathan Rajlich <n@n8.io>
Co-authored-by: Jared Palmer <jared@jaredpalmer.com>
Co-authored-by: Andy Bitz <artzbitz@gmail.com>
Co-authored-by: Andy <AndyBitz@users.noreply.github.com>
Co-authored-by: Gary Borton <gdborton@gmail.com>
Co-authored-by: Drew Bredvick <dbredvick@gmail.com>
Co-authored-by: Jared Palmer <jared@jaredpalmer.com>
Co-authored-by: Andy Bitz <artzbitz@gmail.com>
Co-authored-by: Andy <AndyBitz@users.noreply.github.com>
* Rewrites the CLI unit tests to be TypeScript and use Jest (consistent with the unit tests in the other packages in this repo).
* The file structure of the new test files mirrors that of the `src` directory, so that it's easy to find the relevant tests.
* Code coverage is also properly set up through Jest - you can already see a big increase in coverage from this PR.
* Adds a mock API server framework, with the intention of making it possible to write granular tests of the CLI commands. Using mocks also has the benefit of not requiring `VERCEL_TOKEN` env var to be set, so 3rd party PRs will be able to have their tests run. Ultimately this will also help with test coverage, since we will be writing unit tests that test the commands' code directly.
* Converts `Output` into a proper class (which is subclassed for the mocks).
* remove prefix from codeowners
* remove references from ignore files
* Remove prefix from package json and tests
* Add run js without prefixes
* Rename package folders
* Delete auto generated test files
* Remove now-node in integration test
* Put back deleted vercel json files
* Remove eol
* Add styfle suggestion to comment in utils/run.js
Co-authored-by: Steven <steven@ceriously.com>
