`spawnSync()` does not throw if the command can't be found in the PATH or if an error occurs. If we use `execFileSync()`, it will throw and that was likely the desired behavior in this test utility function.
This adds a new package to the monorepo: `@vercel/remix-entry-server`
The purpose of this package is to provide most of the implementation of
the Remix `app/entry.server.tsx` file with proper support for the Vercel
Serverless and Edge runtimes, specifically in regards to React 18
streaming.
The reason that this package is necessary, as opposed to just updating
our Remix template, is due to the fact that Serverless and Edge runtimes
require a different implementation. This is because the
`react-dom/server` package exports different functions for the Node
(`renderToPipeableStream()`) vs. Edge (`renderToReadableStream()`)
bundles, and thus this package also has two different implementations
(by utilizing the `main` and `browser` fields in `package.json`).
Usage of this package in a Remix application's `app/entry.server.tsx`
file looks like:
```tsx
import handleRequest from "@vercel/remix-entry-server";
import { RemixServer } from "@remix-run/react";
import type { EntryContext } from "@remix-run/server-runtime";
export default function (
request: Request,
responseStatusCode: number,
responseHeaders: Headers,
remixContext: EntryContext
) {
const remixServer = <RemixServer context={remixContext} url={request.url} />;
return handleRequest(request, responseStatusCode, responseHeaders, remixServer)
}
```
Once this package is published then we can update our own Remix template
to utilize it, enabling React 18 streaming for both Vercel runtimes.
We no longer require the memory to be provided in steps of 64mb for
serverless functions.
Instead the memory can now be chosen freely from `128mb` to `3008mb` in
`1mb increments`.
Updates the `vercel.json` schema to reflect that change.
Adds support for server-side rendered Remix using Edge Functions. This runtime can be enabled on a per-page basis, by adding the following to a page within the `app/routes` directory:
```js
export const config = {
runtime: 'edge'
};
```
Additionally, this PR further supersedes the `@remix-run/vercel` runtime adapter, because we will always inject our own server entrypoint. So the logic to ensure that package exists in the project's `package.json` has been removed (so this closes#9011). The only requirement is that the Remix project has `@remix-run/node` as a dependency, which is the case for the vanilla Remix template so I think that's a fair assumption.
To make Edge Functions work, we need to ensure that `remix build` is executed with a few specific configuration values in place, so this change wraps the existing `remix.config.js` file and adds our own to make sure those values are in place (and then cleans itself up after the build command is executed).
Finally, the reading of the Remix config logic was simplified by using the `readConfig()` function from the `@remix-run/dev` package, which also includes the routes manifest, so the hacky `vm` running logic to retrieve the manifest was able to be removed.
Closes#8784.
Closes#9011.
---
# To test this out:
1. Ensure that Remix dependencies are running _at least version `1.5.0`_ (which is when `writeReadableStreamToWritable()` was added to `@remix-run/node`).
2. Add the following line of code to any page in your Remix application’s `app/routes/*` directory:
```jsx
export const config = { runtime: 'edge' };
```
3. Set an Environment Variable on your Vercel Project:
- Name: `VERCEL_CLI_VERSION`
- Value: `https://vercel-git-update-remix-edge.vercel.sh/tarballs/vercel.tgz`
4. Make a deployment, either by running `vercel deploy` in the CLI, or by pushing a Git commit to your repository which has a Vercel Git integration enabled.
In an effort to speed up CI, we should update the lowest common
denominator to Node.js 16
Note: In April, Node.js 14 will reach EOL so we can update tsconfig
targets and ship a major semver at that time.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
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.
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.
These tests will run if one of the conditions is met:
- any change to `./examples`
- any changes to `./packages/frameworks`
The test ensures that examples can build and deploy without errors.
In a future PR, we could improve these tests to make requests to the
test deployment (like we do for probes).
Since turbo and nx only consider `NEXT_PUBLIC_` prefixed env variables for the cache key this ensures we expose variables that affect the build in that format as well so that an incompatible build cache isn't attempted to be leveraged. No additional tests were added here as this related to build cache which can't be reliably tested here.
x-ref: [slack thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1675821643786319)
If there is a monorepo that has one project at the root level we want to
return commands without the relative to root prefixes
---------
Co-authored-by: Chris Barber <chris.barber@vercel.com>
There are times when a request can arrive for a Python function with headers as a list. One of those examples is this header `x-vercel-proxied-for` which apparently is set twice. Example:
`[b'x-vercel-proxied-for', [b'207.81.134.243', b'172.71.147.74']]`
I took a quick scan through the other Python server implementations and I don't think any of them manipulate the value of the HTTP headers, the way the ASGI one does so I think we are good there.
To reproduce:
`curl https://..../ -H "foo: bar" -H "foo: bar"`
Will fail.
Fixes: https://github.com/vercel/vercel/issues/9132
Both `runtime: undefined` and `runtime: nodejs` have the same behavior
but we want to change that in the future.
The first step is to see if `runtime: nodejs` is currently used at all.
Instead of outputting a single SSR function at `/render` path, scan the
build manifest file to determine the proper paths to output the SSR
function at.
When Root Directory setting is used, and/or `vc build --output` is used,
do an intelligent "merge" (move) operation rather than copying the
contents of the build output directory to the destination. This should
overall be faster and avoid disk space issues for larger projects.
Instead of using `pathPrefix` from the Redux store, grab the value
directly from the "BuildArgs" passed to `onPostBuild()`. This value
seems to properly reflect whether or not `--prefix-path` mode was
enabled during the Gatsby build process.
We are getting reports of some larger Gatsby projects running out of
disk space during build which seem to be the result of copying the
static directory multiple times.
So move instead of copying, which doesn't fully solve the problem, but
it does kick the can down the road a bit. Very large projects would
probably still hit the disk limit at some point. Anyways, moving is
faster than copying so this is still a net positive.
The `.vercel/output` directory gets wiped away when `--output` is _not_ being used, but it should be deleted even when the flag is being used so that build scripts targeting Build Output API directly always start with a fresh slate.
1. `commandForIgnoringBuildStep` should be run at the project directory level not the monorepo root level
2. Simplifying the `installCommand` because doesn't need the relative root unless it is `npm`
Github Action for actions/cache has an issue that could cause it to take
1 hour and then timeout while trying to restore the cache.
Since `actions/setup-node` is no longer used to restore the pnpm cache,
the `timeout-minutes: 5` doesn't do anything for this action.
Instead we need to put an env variable on the `actions/cache` Github
Action to actually set the restore cache timeout.
```
env:
SEGMENT_DOWNLOAD_TIMEOUT_MINS: 5 # See https://github.com/actions/cache/issues/810
```
- See discussion here https://github.com/vercel/vercel/discussions/9340
- Related to actions/cache#810
- Follow up to #8639
Around 6 months ago, @styfle brought to my attention how `rename()` in build-utils used `reduce()` and could be written better. So, I rewrote it.
Before, the code would create a new `Files` object and copy the contents of the previous `Files` object. This caused heavy garbage collection and memory thrashing.
Instead, I created a single `Files` object, then add the files to it.
Results:
| # Files | Before | After |
|---|---|---|
| 1,000 | 75 ms | 1 ms |
| 10,000 | 10.6 s | 7 ms |
| 20,000 | 44.6 s | 16 ms |
| 30,000 | 105.5 s | 22 ms |
| 100,000 | Too long | 73 ms |
`.vercel/output` is already made fresh when running `vc build`, so the
plugin should not be doing this. In fact, it makes the `builds.json`
file be wiped away, which we don't want to happen.
Right now, static-build will add the necessary Gatsby plugins to the project's `package.json` at build-time, which has been bothersome for package managers when using a frozen lockfile.
Another issue with it is that we install `latest` version of the plugin, so the version used becomes disjointed from the CLI version itself, which leads to unpredictability when trying to debug issues or help users roll back to a previous behavior if something breaks.
So instead of patching `package.json` directly, include the plugins as deps of static-build itself, and create symlinks to those paths into the project's `node_modules` directory.
We currently don't make it obvious when `next export` is being leveraged which de-opts features like `middleware`, `rewrites`, `redirects`, etc. so this adds a notice to let users know when we are using `next export` output.
Adds some unit tests for the gatsby injection logic.
These are net new since we've heavily changed the injection logic. The tests and fixtures in `build-fixtures` and `builds.test.js` are seemingly not executed. We may delete those here too.
The `NODE_OPTIONS` env var value is wrong here and we shouldn't be overriding the user's setting to begin with.
Typically, it will be assigned in a build container or project settings.
We had Turborepo miscofigured. The `dependsOn: ["^build"]` means run all dependencies' build script, but it doesn't mean the package's build script will run first. For tests, it should always `dependsOn: ["build"]` (without the upcaret) instead to ensure its own build is complete before testing. I also learned that `outputs: []` can be dropped now since thats the default behavior.
We need to ensure that `@vercel/gatsby-plugin-vercel-builder` is executed as the very last plugin, which Gatsby itself doesn't really support in the plugins listing. So instead we'll patch the `gatsby-node` file to invoke the plugin in the project's own `onPostBuild()` hook, which does get executed last. The patching is similar to how is done with the `gatsby-config` file.
Astro v2 was released today. It includes [improved support for caching
all hashed build
assets](https://docs.astro.build/en/guides/upgrade-to/v2/#changed-_astro-folder-for-build-assets)
by gathering these all in a single `_astro` directory in build output
(previously these ended up in a number of different places).
This PR updates the Vercel frameworks config to provide out-of-the-box
immutable caching for these assets.
Co-authored-by: Steven <steven@ceriously.com>
Right now we create the SSR serverless function at path `_ssr`, and then symlink all the other pages to that function.
Instead just make the first page encountered be the "real" function, and symlink all the other pages to that endpoint.
Previously, the page-data Serverless Function and SSR Serverless Function were two distinct functions. They had almost identical file contents and just slightly different handler logic. So here we merge the handler logic into a single function and re-use the same Serverless Function for both page-data and SSR.
This simplifies the output quite a bit and deletes a good amount of code, and helps with build output size, cold boot times, etc.
So that the test runs get invalidated by Turbo when code changes within one of the plugin files. This is to avoid a PR breaking something in a plugin, but we don't notice it because the static-build tests still "pass" due to cache hit.
This function can sometimes give a TypeScript error if @types/node says 'code' should be a `number | null` and yet the code is returns as a `number`:
```
@vercel/build-utils:build: src/fs/run-user-scripts.ts(140,13): error TS2322: Type 'number \| null' is not assignable to type 'number'.
@vercel/build-utils:build: Type 'null' is not assignable to type 'number'.
```
I'm not sure if there are any other projects that depend on `@vercel/build-utils`, but it doesn't appear that the Vercel CLI nor the build container use this `execAsync()` function. If I'm mistaken, feel free to close this PR.
As this removal is a breaking change, setting the semver to major and not auto-merging unless others are in agreement.
Gridsome was not updated for [more than 2 years](https://www.npmjs.com/package/gridsome) and still relies on Webpack 4 what makes it incompatible with >= Node.js 17.
To make the example still deployable on Vercel, this adds an engine restriction to the `package.json` for that example.
Same as #9007.
* Sets a valid number of seconds for DSG expiration (10 minutes - do we want to make that configurable somehow?)
* Sets the `group` of DSG pages, so that the page-data and SSR pages are associated
* Outputs SSR/DSG pages with `/index.html` suffix so that those paths are accessible
* Updates SSR and page-data functions URL path parsing logic to handle querystrings and the `index.html` scenario
* Remove the unnecessary `rewrite` related to page-data URL paths
* Remove the page-data function static file fallback handling (they are accessible as just regular static files)
* Correct the path for the page-data endpoing when the root-level index page is SSR/DSG
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.
This PR attempts to balance the tests so they run concurrently and therefore faster.
I also sorted the tests so they are deterministic when splitting/chunking.
Instead of always including empty directories in `glob()`, make it an
opt-in behavior because technically it's a breaking change to include
them by default.
These were missing from the compiled ncc build of `helpers.ts`, and thus causing an error at runtime because the deps are not available within the Serverless Function.
The previous delay of 1500ms was causing some users to hit the API rate limits. This doesn't normally happen with a single deployment, but it can happen with several concurrent deployments (for example a monorepo with many projects).
We don't need to be polling so often, so this PR changed the polling delay to the following:
- During 0s-15s: check every 1 second
- During 15s-60s: check every 5 seconds
- During 1m-5m: check every 15 seconds
- During 5m-10m: check every 30 seconds
Update `@vercel/client` to send empty directory entries to the `POST` create deployment endpoint. This makes it so that CLI deployments will have empty directories re-populated in the build-container when doing `vc deploy`.
Follow-up to #9103.
In [a different PR](https://github.com/vercel/vercel/pull/9009), detecting frameworks by package name will also provide framework version metadata to the build. Should we update these framework detectors to look up their respective packages or were they not doing that already for a reason?
I left the old detectors in place as fallbacks, which looks like:
```
some: [
{
path: 'package.json',
matchContent:
'"(dev)?(d|D)ependencies":\\s*{[^}]*"remix":\\s*".+?"[^}]*}',
},
{
path: 'remix.config.js',
},
],
```
Please review carefully.
This PR:
- updates `packages/frameworks` to have most supported frameworks specify which dependency version should reflect the overall framework version
- updates `packages/fs-detectors` to allow framework detection that returns the full `Framework` record instead of just the slug
- updates `packages/next` to return the detected Next.js version in the build result
- updates `packages/cli` to leverage these changes so that `vc build` can add `framework: { version: string; }` to `config.json` output
The result is that Build Output API and supported frameworks will return their framework version in the build result of `vc build` when possible, which is used by the build container when creating the deployment. The dashboard later retrieves this value to display in richer deployment outputs.
Supports:
- https://github.com/vercel/api/pull/15601
- https://github.com/vercel/front/pull/18319
---
With the related build container updates, we get to see Next.js version in the build output. You'll see this with BOA+Prebuilt or a normal deploy:
<img width="1228" alt="Screen Shot 2022-12-09 at 2 48 12 PM" src="https://user-images.githubusercontent.com/41545/206793639-f9cd3bdf-b822-45dd-9564-95b94994271d.png">
---
### The Path to this PR
I went through all the supported frameworks and figured out how to best determine their versions. For most of them, we can check a known dependency's installed version number.
We can get most of the way only checking npm. For a handful, we'd have to support Go/Ruby/Rust/Whatever dependencies.
I started with a more complex method signature to allow for later expansion without changing the signature. It looked like this, in practice:
```
async getVersion(dependencies: DependencyMap) => depedencies['next']
```
However, after checking all currently supported frameworks, I don't think this will end up being necessary. It also has the constraint that all dependencies have to be gathered and presented to the function even though it only needs to check for one or two. That's not a huge deal if we have them already where we need them, but we don't. We could use a variant here where this function does its own lookups, but this seemed unnecessary and would beg for duplication and small variances that could cause bugs.
Further, if we only look at `package.json`, we're going to either see a specific version of a version range. To be precise, we have to look at the installed version of the package. That means checking one of the various types of lockfiles that can exist or poking into node_modules.
If we poke into node_modules to detect the installed version, we introduce another point where Yarn 3 (default mode) will not be supported. If we read lockfiles, we have to potentially parse `npm`, `pnpm`, and `yarn` lockfiles.
If we use `npm ls <package-name>`, that also fails in Yarn 3 (default mode). We could accept that and go forward anyway, which would look like:
```
const args = `ls ${packageName} --depth=0 --json`.split(' ');
const { stdout } = await execa('npm', args, { cwd });
const regex = new RegExp(String.raw`${packageName}@([\.\d]+)`);
const matches = stdout.match(regex);
if (matches) {
return matches[1];
}
```
But it turns out there's a `--json` option! That's what I ended up using, for now.
We could explore the lockfile route more, but after some initial digging, it' non-trivial. There are 3 main lockfiles we'd want to check for (npm, pnpm, and yarn) and there are different lockfile versions that put necessary data in different places. I looked for existing tools that parse this, but I didn't find any. We could certainly go down this path, but the effort doesn't seem worth it when `npm ls` gets us really close.
---
### Follow-up Versioning
Now that we know how to determine version per framework, we can vary configuration by version. In a future PR, we could allow a given value to vary by version number:
```
name: (version) => {
if (semver.gt(version, '9.8.7')) {
return 'some-framework-2''
}
return 'some-framework';
}
```
However, it may still be easier to differentiate significant versions by adding multiple entries in the list.
Adds support for `remix.config.mjs` and `remix.config.cjs` and
also updates the example/fixtures to the latest version of Remix.
See: https://github.com/remix-run/remix/pull/3675
https://linear.app/vercel/issue/VCCLI-377/rollback-failing-for-enterprise-teams
When running `vc rollback` for a deployment belonging to another team, the command will fail requesting the rollback. Technically, the command should have failed trying to get the deployment. This PR checks that the current team matches the deployment being rolled back.
This PR also cleans up a bunch of deployment related things. There were 3 functions to get a deployment and now there's just one which uses the latest v13 API. Get deployment error handling now throws instead of returning an error. The `Deployment` type definition has been updated to match the v13 response and mock deployment data was also updated.
Updates the `static-build` injector to use the new plugin.
Still need to verify somehow that the newly published plugin is working as expected. It should be fine since it was a copy-paste from the previous plugin repo, but always good to verify before we break everything!
This PR also updates the README in `@vercel/gatsby-plugin-vercel-analytics`
This PR migrates https://github.com/vercel/gatsby-plugin-vercel to this
repo so that we can eventually integrate into our monorepo tooling.
Since it currently requires Node.js v12 to be built, I've manually
built, copied, and committed the package as it exists now so that we can
publish a stable v1 of `@vercel/gatsby-plugin-vercel-analytics`.
After work completes on adding support for Gatsby v4, I will come back
to this package and update it to Node.js v16 so that it can be
integrated properly into the repository's tooling.
🚨 DO NOT SQUASH MERGE 🚨
Adds support for auto injection into Gatsby's new ESM config format. Only injects if the `gatsby-config.mjs` is present, and continues to default generation of `gatsby-config.js`
This PR generates lockfiles for the various monorepo build tests and updates the package versions to their latest within the major. This should help make these tests less flaky.
Related issue: https://vercel.slack.com/archives/C017QMYC5FB/p1673025728939139
Updates the screenshot used for the Next.js template that shows up on the import/new project flow. The asset has been updated on Cloudinary (`/front/import/nextjs`) and this PR updates the version # of the url.
- 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>
When you are on this page, creating a project the image here is the screenshot of an example project in the `Vercel Examples` enterprise. However that was not working:
<img width="1060" alt="Screen Shot 2023-01-03 at 2 26 58 PM" src="https://user-images.githubusercontent.com/74699/210451850-8208f42b-de43-4ac4-a1fe-b90d88fe86d8.png">
It does this by hitting the API. In this case the problem is that there is a trailing slash on the domain name, causing the API to fail:
<img width="477" alt="Screen Shot 2023-01-03 at 2 29 48 PM" src="https://user-images.githubusercontent.com/74699/210452032-2e32ae61-df29-48b4-b79f-93f5bcf299d3.png">
So this removes that trailing, but I'll see if I can tighten this up as well so in the future it doesn't matter if there is a `/` there.
FYI: this passes unit tests in framework, because it passes the URL in demo through to `URL` and grabs the hostname, which strips out the `protocol` and trailing `/`. Perhaps we should do the same on front.
In July 2022, VitePress changed (https://github.com/vuejs/vitepress/pull/931) the output directory from `.vitepress/dist` to `docs/.vitepress/dist`, however the framework detector was still referencing the old .vitepress/dist` output directory.
There are some edge-case situations where a dependency or build process is expecting an empty directory to exist, and this expectation would fail currently because `glob()` does not return directory entries.
So update `glob()` to return entries for empty directories, which are also re-created properly when passed to the `download()` function.
This adds a `link()` helper function to the `Output` class that is inspired by the `terminal-link` npm package.
The main difference with this version is that it's more tightly integrated with the `Output` class for the purposes of being able to toggle hyperlinks support on/off for [unit tests](4a54b19f46/packages/cli/test/unit/util/output/create-output.test.ts) by setting the `output.supportsHyperlink` boolean.
> **Note:** Since hyperlinks are still a relatively new feature, and users might not yet understand how to interact with them, we should only use this function for progressive enhancement scenarios at this time, and _not_ as part of a critical UX.
When adding an alias, the server can return a 400 Bad Request under these circumstances:
1. Invalid alias: no alias, empty string, null alias, alias domain is invalid, alias is not public, alias is not a subdomain (code: `'invalid_alias'`)
2. The deployment is indeed not ready (code `'deployment_not_ready'`)
3. The cert for the provided alias is not ready (code `'cert_missing'`)
4. There was an error assigning the alias (code varies)
`vc alias add` will treat all 4 of those bad request errors as the deployment "is not ready". Instead of treating all 400's as not ready, only return `DeploymentNotReady` if the `code` is set to `'deployment_not_ready'`.
The CODEOWNERS file had an error referencing the `@vercel/edge-function` team, which does not exist. I assume this is supposed to be `@vercel/edge-compute`, but please confirm.
There are a [few edge-related teams](https://github.com/orgs/vercel/teams?query=edge).
### 🔖 What's in there?
Because Typescript's `libdom` does not have [`static Response.json()`](https://github.com/microsoft/TypeScript-DOM-lib-generator/issues/1444) (which modern browsers and edge runtimes are supporting), Typescript users can't use easily use it.
This helper fills the gap.
### 🧪 How to test?
It's covered with unit tests
🎉 Kit is live! 🎉
Merge prior to #9030. Manually updates Kit to latest (will need to have
a commit pushed after 1.0 goes live on NPM).
Co-authored-by: Steven <steven@ceriously.com>
According to AWS Lambda official documentation:
> The Lambda documentation, log messages, and console use the abbreviation MB (rather than MiB) to refer to 1024 KB.
https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
This is also a convenient thing for us since CF Limits are in base-2 (even they are printed as base-10).
Fixes flakey tests / CI:
- git metadata test for corrupted `.git` directory
- version identifier for `build-utils` being using in `fs-detectors`'s `devDependencies`
- bad import from `../dist/..`
### 📖 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
Allow the `ls` commands to have a `--limit` option that allows a user to fetch up to 100 records per page. Currently the default is 20, but the API allows up to 100. This keeps the default, if unspecified at 20.
Fixes: https://linear.app/vercel/issue/VCCLI-244/add-limit-option-all-the-ls-subcommands
This adds in `ls --limit` into:
- [x] `alias ls`
- [x] `certs ls`
- [x] `dns ls`
- [x] `domains ls`
I note that `env` has an `ls` command, but it doesn't have a pagination command and [looking at the API](https://vercel.com/docs/rest-api#endpoints/projects/retrieve-the-environment-variables-of-a-project-by-id-or-name) it doesn't support pagination or limit.
Wasn't sure if I should add in `-L` as a short cut to `--limit`, seems like a good idea.
~Couldn't find any tests that cover this API, but I could be looking in the wrong place, this is the first pull request, so my apologies if I've missed it. But I'll take another look tomorrow and leave it in the draft state for now.~
Added in unit tests for each of the commands and mocks for those unit tests, which is has caused this PR to get quite a bit larger, sorry about that.
Of note for reviewers, there were a few places where I changed `console.log` to `output.log` to get the output passed to the tests - as far as I can tell everything works on the command line and in tests.
### 📋 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
The umi example currently uses `umi@2` which uses `webpack@4` under the hood to build.
Because of this issue https://github.com/webpack/webpack/issues/14532 Webpack@4 is no longer able to run on Node.js 17+.
Since we use [Node.js 18 as default](https://vercel.com/changelog/node-js-18-lts-is-now-available) for new projects, this example currently breaks when it gets deployed.
Temporary fix is here to ensure that a Node.js version below 17 is used in the meantime.
Augments the `BuildResultV2Typical` type to support `framework` and `frameworkVersion` for use in Richer Deployment Outputs.
I added this to a new `meta` object because it contains data about the result, not really part of the result.
---
Supports a related builder container update.
The `vc rollback` command provides the ability to redeploy a previous
deployment and check the status of a rollback request.
#### Requesting a rollback
vc rollback <id | url>
Upon requesting a rollback, the command will being a status polling loop
for 3 minutes. This timeout can be adjusted via the `--timeout <value>`
option which accepts time formats such as `30s` or `2m`. A timeout of
`0` (zero) will skip the status polling and immediately exit after
successfully requesting a rollback.
#### Querying rollback status
vc rollback
vc rollback status
The `status` action will return the most recent rollback info within the
last 3 minutes.
### Related Issues
>
https://linear.app/vercel/issue/HIT-117/cli-add-support-for-vc-rollback-deployid
>
https://linear.app/vercel/issue/HIT-118/cli-add-support-for-vc-rollback-[status]
### 📋 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
The default routes for Astro are redirecting all non-existing files to
`index.html`, which means that the `404.html` page is not used, and
instead `index.html` is shown for all not found pages.
Astro outputs files for each page (ie. `about.html`, `blog.html`, ...)
so the `{handle: 'filesystem'}` route should be enough to route all
existing pages correctly.
The missing part to ship this fix is to answer the following question:
can we safely assume that Astro will always output a `404.html` file?
Internal ref: https://github.com/vercel/customer-issues/issues/638
Co-authored-by: Okiki Ojo <okikio.dev@gmail.com>
Co-authored-by: Nathan Rajlich <n@n8.io>
Co-authored-by: Steven <steven@ceriously.com>
### Related Issues
Fixes: [slack
thread](https://vercel.slack.com/archives/C035J346QQL/p1669508061056179)
### 📋 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
Fixes https://github.com/vercel/next.js/issues/43357
### 📋 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
- [ ] 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
Since introducing `vc build`, we no longer have isolated builds. This means we can share the cache across builds and improve TS compile across multiple builds.
For example, `api/foo.js` and `api/bar.js` are two different builds but they will likely share the same `tsconfig.json`. So this PR caches the initialization used before running the TS compiler so that it can be shared between builds of the same deployment.
In one customer build, we saw deployment time drop from 14 min to 7 min.
- Related to https://github.com/vercel/customer-issues/issues/925
### Related Issues
This fixes up a few links that had errors I found when scanning through
the code.
### 📋 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
`--cwd` is handled globally in the CLI entrypoint file, so if a relative path is used then it would be applied twice in `vc build` since it was _also_ handling `--cwd`. So remove `vc build`'s logic for it.
Fixes https://github.com/vercel/vercel/discussions/8948.
`json5` can be moved to a dev dependency since `ncc` bundles it into the output.
### 📋 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
- [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
A simple update to the framework array, updating the blitz properties to
match the legacy framework. This PR detects a `blitz.config.(ts|js)`
file which is specific to the legacy framework. With the blitz 2.0
update the framework detection should automatically be next.js.
`pnpm` is our package manager of choice. This repository contains
framework starter templates, which check-in lockfiles to speed up clone
& deploy time. This PR updates a few frameworks to use `pnpm` instead of
`yarn` or `npm`.
- Updates Gatsby to Gatsby 5 given Node.js 18 support
- Updates to latest Nuxt 3 template for stable version
- Updates Astro to latest stable version, previously on RC
- Updates Angular to v15, previously on v13
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>
### Related Issues
Includes a guard checking for `vercel-build` and a LD flag to control
rollout.
### 📋 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
Adds support for package.json based turbo configuration.
Includes test.
Confirmed with Turbo that `turbo.json` takes precedence over
`package.json` based config so that is how it is processed here.
### 📋 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
No related issue, this is a drive-by fix
### 📋 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
### Related Issues
A customer issue was raised that web-vitals analytics were not working for their Gatsby application, even though this is meant to be zero config.
It turns out the issue is due to their `gatsby-config` file being declared as a `ts` file, rather than `js`. This is perfectly valid and supported in Gatsby.
However, the static-build modifications that are made to automatically add the `gatsby-plugin-vercel` only apply to existing `js` files.
This lead to their deployments containing both a `js` and `ts` version of `gatsby-config`. Luckily, the `ts` version has higher precedence, so _only_ web-vitals were affected.
Closes https://linear.app/vercel/issue/FLA-364/investigate-gatsby-and-nuxt-data-issues
#### 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
Adds support for comments in JSON configs and skips operation when root directory is null or `'.'`
### 📋 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
The `readOutputStream()` module was counting "data" events, not lines specifically, and was failing for me locally. So that was removed, and updated the tests that were using it to use the `line-async-iterator` module instead to be more explicit and be able to perform assertions on a per-line basis.
### Related Issues
Improves how `vc build` handles monorepos. In short, this introduces
monorepo manager detection logic and then some helpful defaults so users
don't have to manually specify a `buildCommand` or `installCommand` when
linking a project within a monorepo.
### 📋 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
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.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
On Windows, Python 3 is unable to listen on `0.0.0.0` and errors with:
```
[WinError 10049] The requested address is not valid in its context
```
The only solution I found is to bind to `127.0.0.1` or `localhost`. I've run into issues before with using `localhost`, so I chose to go with `127.0.0.1` and Windows (and macOS) seems to be happy.
### 📋 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
- [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
We have a link to an error page here:
https://github.com/vercel/vercel/blob/main/packages/cli/src/commands/deploy/index.ts#L873,
however that page is currently a 404.
This is an attempt to explain the error a bit more. Because there are
many possible causes of a deployment error, this mostly focuses on
explaining how to get to the logs.
### Related Issues
Fixes https://github.com/vercel/vercel/issues/1732.
### 📋 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
Co-authored-by: Nathan Rajlich <n@n8.io>
Co-authored-by: Chris Barber <chris.barber@vercel.com>
### Related Issues
x-ref: [slack
thread](https://vercel.slack.com/archives/C01224Q5M99/p1667927545637489?thread_ts=1664536480.045539&cid=C01224Q5M99)
### 📋 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
This ensures we properly route dynamic routes with segments in the
middle of the path for rsc paths and also ensures we normalize the
header values from the routes-manifest correctly.
x-ref: https://github.com/vercel/next.js/issues/42364
x-ref:
https://github.com/vercel/next.js/actions/runs/3415662540/jobs/5685787894
### 📋 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
Required for https://github.com/vercel/next.js/pull/42482
### 📋 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
Updates @types/node to the latest version within the v14 major (based on `npm view @types/node`)
```
❯ npm view @types/node@'>=14.0.0 <15.0.0' version | tail -1
@types/node@14.18.33 '14.18.33'
```
This PR also fixes the various necessary type changes
### 📋 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
https://github.com/vercel/api/pull/15009 broke one of our integration tests. This PR fixes it.
### 📋 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
@@ -6,7 +6,7 @@ Please read our [Code of Conduct](CODE_OF_CONDUCT.md) and follow it in all your
## Local development
This project is configured in a monorepo, where one repository contains multiple npm packages. Dependencies are installed and managed with `yarn`, not `npm` CLI.
This project is configured in a monorepo, where one repository contains multiple npm packages. Dependencies are installed and managed with `pnpm`, not `npm` CLI.
To get started, execute the following:
@@ -14,21 +14,32 @@ To get started, execute the following:
git clone https://github.com/vercel/vercel
cd vercel
corepack enable
yarn install
yarn bootstrap
yarn build
yarn lint
yarn test-unit
pnpm install
pnpm bootstrap
pnpm build
pnpm lint
pnpm test-unit
```
Make sure all the tests pass before making changes.
### Running Vercel CLI Changes
You can use `pnpm dev` from the `cli` package to invoke Vercel CLI with local changes:
```
cd ./packages/cli
pnpm dev <cli-commands...>
```
See [CLI Local Development](../packages/cli#local-development) for more details.
## Verifying your change
Once you are done with your changes (we even suggest doing it along the way), make sure all the tests still pass by running:
```
yarn test-unit
pnpm test-unit
```
from the root of the project.
@@ -91,7 +102,7 @@ When you run this script, you'll see all the imported files. If anything file is
Sometimes you want to test changes to a Builder against an existing project, maybe with `vercel dev` or actual deployment. You can avoid publishing every Builder change to npm by uploading the Builder as a tarball.
1. Change directory to the desired Builder `cd ./packages/node`
2. Run `yarn build` to compile typescript and other build steps
2. Run `pnpm build` to compile typescript and other build steps
3. Run `npm pack` to create a tarball file
4. Run `vercel *.tgz` to upload the tarball file and get a URL
5. Edit any existing `vercel.json` project and replace `use` with the URL
We do try to keep issues in this repository focused on the vercel command line and related code.
At this point we think that this issue is best handled by our friendly Vercel support team. They can be found by contacting them at: https://vercel.com/help#issues
If you think closing of this is a mistake, then please re-open this issue and we'll take another look :bow:
@@ -33,6 +33,14 @@ For details on how to use Vercel, check out our [documentation](https://vercel.c
## Contributing
This project uses [pnpm](https://pnpm.io/) to install dependencies and run scripts.
You can use the `dev` script to run local changes as if you were invoking Vercel CLI. For example, `vercel deploy --cwd=/path/to/project` could be run with local changes with `pnpm dev deploy --cwd=/path/to/project`.
See the [Contributing Guidelines](./.github/CONTRIBUTING.md) for more details.
When deploying this project, there was not a successful deployment into the `READY` state.
## How to Fix It
This is a generic error to catch problems in the deployment. The error is likely to vary depending on the deployment and the conditions at the time.
Try looking in the logs for information about the deployment and the failure, this could be done at (vercel.com)[https://vercel.com]. You can also use the `vc logs` command to display the build logs for the deployment.
This might not be a permanent error and retrying the deployment might also resolve it.
`@now/next` has two modes: `legacy` and `serverless`. You will always want to use the `serverless` mode. `legacy` is to provide backwards compatibility with previous `@now/next` versions.
`@vercel/next` has two modes: `legacy` and `serverless`. You will always want to use the `serverless` mode. `legacy` is to provide backwards compatibility with previous `@vercel/next` versions.
The differences:
@@ -27,7 +27,7 @@ Serverless:
- Runs `npm run now-build`
- Does not run `npm install --production` as the output from the build is all that's needed to bundle lambdas.
- No runtime dependencies, meaning smaller lambda functions
- Optimized for fast [cold start](https://vercel.com/blog/serverless-ssr#cold-start)
6. Make sure you have the correct Node.js version selected for your build step in your project settings (`https://vercel.com/[username]/[project]/settings`)
This could be caused by a misconfigured "Build Command" or "Output Directory" for your Next.js project.
This error is often caused by a misconfigured "Build Command" or "Output Directory" for your Next.js project.
#### Possible Ways to Fix It
In the Vercel dashboard, open your "Project Settings" and draw attention to "Build & Development Settings":
1. Ensure that the "Build Command" setting is not changed, or that it calls `next build`. If this command is not changed but you are seeing this error, double check that your `build` script in `package.json` calls `next build`.
2. Ensure that the "Output Directory" setting is not changed. This value almost never needs to be configured, and is only necessary if you override `distDir` in `next.config.js`.
3. For `next export` users: **do not override the "Output Directory"**. Next.js automatically detects what folder you outputted `next export` to.
1. Ensure that the "Build Command" setting is not overridden, or that it calls `next build`. If this command is not overridden but you are seeing this error, double check that your `build` script in `package.json` calls `next build`. If `buildCommand` exists in `vercel.json`, make sure it calls `next build`.
2. Ensure that the "Output Directory" setting is not overridden. This value almost never needs to be configured, and is only necessary if you override `distDir` in `next.config.js`. If `outputDirectory` exists in `vercel.json`, remove that property.
3. For `next export` users: **do not override the "Output Directory"**, even if you customized the `next export` output directory. It will automatically detects the correct output.
In rare scenarios, this error message can also be caused by a Next.js build failure (if your "Build Command" accidentally returns an exit code that is not 0).
Double check for any error messages above the Routes Manifest error, which may provide additional details.
Run `ng serve` for a dev server. Navigate to `http://localhost:4200/`. The app will automatically reload if you change any of the source files.
Run `ng serve` for a dev server. Navigate to `http://localhost:4200/`. The application will automatically reload if you change any of the source files.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
