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 fixes customer issue
https://github.com/vercel/customer-issues/issues/1310 which identified
an issue with the `redeploy` command.
`redeploy` should not default the `target` to `'production'` as an
`undefined` target is meant to mean `'preview'`.
These packages already don't get published since they have `private: true`, but adding to the "ignore" configuration also removes them from the selection prompt when executing the `changeset` CLI command.
Previously, `createProject()` only allowed a string `name` to be provided, and another API call would need to be done after creation with `updateProject()`. This should not be necessary since the `POST` endpoint can accept additional properties already.
Reverts vercel/vercel#8681
We ran an experiment here a while ago but it had flaky results.
This PR cleans up the experiment code, and reverts to the previous behavior.
This PR adds a new utility for generating `help` output for CLI
commands. Backed by a JSON data structure that represents the commands,
this utility uses deterministic functions for generating the different
output sections (such as `options` and `examples`). This change will let
contributor easily add/modify command details. The data structure is
also used by the CLI to generate the args parsing structure for the
`deploy` command. Optimistically, this same data structure can be used
to generate documentation output for `front` such that the online docs
will match the `help` output.
---------
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
This will solve two of the warnings from [Socket.dev](https://socket.dev/npm/package/vercel):
<img width="1126" alt="image" src="https://github.com/vercel/vercel/assets/229881/c890c973-4f5a-44d9-9b96-2580a1e40ed0">
This preinstall script isn't necessary to run Vercel CLI, its only used to improve the error message in two cases:
- The system has `node` version prior to 14.x (3 years ago)
- The system still has `now` installed but should be using `vercel` (last shipped 3 years ago)
The usage of `preinstall` scripts have gone out of style due to security audits so we should remove this script now.
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## vercel@31.0.1
### Patch Changes
- Updated dependencies
\[[`aa734efc6`](aa734efc6c)]:
- @vercel/next@3.8.8
## @vercel/next@3.8.8
### Patch Changes
- [next] Ensure RSC paths handle basePath
([#10155](https://github.com/vercel/vercel/pull/10155))
The `getNodeBinPath()` function is problematic because it assumes that commands are installed in the `node_modules` directory alongside the detected lockfile. This works fine the majority of the time, but ends up not being the case when using a monorepo that uses a package manager in "linked" mode (i.e. pnpm by default).
Consider the following:
```
.
├── pnpm-lock.yaml
├── node_modules
├── blog
│ ├── node_modules
│ │ ├── hexo -> .pnpm/hexo@3.9.0/node_modules/hexo
```
In this setup, adding the root-level `node_modules/.bin` would not make the `hexo` command be visible in the `$PATH`.
To solve this issue, the new `getNodeBinPaths()` function returns an array of all directories up to the specified `root`, which can then be placed into the `$PATH`. It's also more efficient (synchronous) since it does not need to scan for a lockfile anymore (the `root` needs to be specified explicitly).
The new function is being used in `@vercel/next` and `@vercel/static-build`.
The `traverseUpDirectories()` function from CLI was moved to `build-utils` to implement this function. Consequently, that makes the implementations of `walkParentDirs()` and `walkParentDirsMulti()` simpler, since it's using this generator now.
In order to promote a preview deployment, we want to make sure the user knows that this is not typical. Now the `--yes` flag is required to make this work.
Production was recently changed to make redirect responses return the text "Redirecting..." without the destination nor status code in the text.
This caused some tests to start failing, so update `vc dev` to match this new behavior and update the relevant tests.
This changes the error when a token is invalid or expired from
```
Error: Could not retrieve Project Settings. To link your Project, remove the `.vercel` directory and deploy again.
Learn More: https://vercel.link/cannot-load-project-settings
```
to a better error
```
Error: The specified token is not valid. Use `vercel login` to generate a new token.
```
- This could be considered a follow up to
https://github.com/vercel/vercel/pull/7794
`LocalFileSystemDetector#readdir()` was throwing an error when a symlink was encountered, due to `fs.readdir()` `withFileTypes: true` option performing an lstat instead of a stat operation.
So re-implement the `readdir()` logic to use `fs.stat()` so that the symlink is resolved (only "dir" and "file" types are expected in the result).
When showing the Project selector and there's more than one Project matched given the current cwd, only show the matched Projects instead of all Projects listed in the `repo.json` file.
When `vc deploy` happens, it was forcing a `true`/`false` value for `autoAssignCustomDomains`. This overwrites the project setting in some cases, which is not what we want.
If a CLI command or API call explicitly wants to force `autoAssignCustomDomains` on or off, it can. Otherwise, the project setting value should be used.
This PR only sets `autoAssignCustomDomains` to `false` when the `--skip-domain` flag is passed. Otherwise, the value is `undefined` so that the project setting can take effect.
The code for these two are almost identical, so consolidate into one codebase.
Also adjusts the `pnpm test` script to allow for specifying a file name to be executed, instead of running all tests.
Superceded by the `findProjectsFromPath()` function which may return multiple matches, and it was only being used in tests.
The relevant tests have been updated to use the multiple matches version instead, and updated to include the case where multiple matches are returned.
__Note:__ No changeset for this one since it's an internal function being removed, and doesn't need to be referenced in the public changelog.
When repo linked, `vc deploy --prebuilt` will change working directory to the Project root directory, instead of the repo root, so that the project's local `.vercel/output` directory is what gets uploaded + deployed.
This is a follow up to PR #9892 which changed the default to `.env.local`.
Now that we know local files should never be committed to git, we can automatically add `.env*.local` to `.gitignore`. Note that this is the same ignore pattern that ships with create-next-app [as seen here](06abd63489/packages/create-next-app/templates/app/js/gitignore (L28)), so most Next.js users won't see anything change.
See the related [Linear ticket](https://linear.app/vercel/issue/VCCLI-461/)
ncc has an issue with detecting + rewriting this file path for some reason. Moving to a helper function should work around that issue.
Fixing:
```
Error: ENOENT: no such file or directory, open '/node_modules/vercel/projects/VERCEL_DIR_README.txt'
```
When repo linked, `vc dev` already works fine when run from the root of the repo. This change makes it so that `vc dev` also works as expected when executed within a project subdirectory.
When the repo is linked to Vercel with `vc link --repo`, the `vc build` command should be invoked from the project subdirectory (otherwise the project selector is displayed). The output directory is at `<projectRoot>/.vercel/output` instead of at the repo root.
When no content type header is sent to an API request during `vc dev`, the request fails:
```
/Users/smassa/source/vercel/vercel-2/node_modules/.pnpm/content-type@1.0.4/node_modules/content-type/index.js:108
throw new TypeError('argument string is required')
^
TypeError: argument string is required
...
```
This comes from some runtime type validation happening in the `content-type` package, for which we do not have types, which is why typescript didn't catch this.
When the repo is linked to Vercel with `vc link --repo`, the `.vercel` directory will be created at the _project root_ instead of the _repo root_, and will still contain the `project.json`.
The difference is that the `orgId` and `projectId` props will not be present in the `project.json` file when repo linked, since that information is available at the root level `repo.json` file.
Adds async iterator helper function for interacting with endpoints that have pagination.
Implemented for use with `vc bisect` (fetching deployments) and `vc link --repo` (fetching projects).
When a project has a `.npmrc` containing `use-node-version`, package managers (notably `pnpm`) will download the specified Node.js version. This is not the correct way as it can lead to `pnpm` downloading Node.js 18 or newer which depends on a version of GLIBC that is not present in the current AWS image. The proper way is to set the `"engines"` in the `package.json`.
<img width="468" alt="image" src="https://github.com/vercel/vercel/assets/97262/0974cf05-6a11-4d95-88e8-13affc4aad2a">
Discussion: https://github.com/orgs/vercel/discussions/2436
### Description
This ensures the Summary job always runs to check if any test failed and
cause itself to fail as well.
This allows us to dynamically add as many concurrent jobs as we want but
only have one (Summary) marked as required.
### Testing
I verified this worked by making a change to `@vercel/static-config`
which is not required and the Summary check failed:
https://github.com/vercel/vercel/actions/runs/5136560652/jobs/9243924596
Then I reverted it so that the test was passing and the Summary check
passed:
https://github.com/vercel/vercel/actions/runs/5137401343/jobs/9245554297
This is a re-application of #10022 (which was reverted in #10032), but with the addition of `changeset tag` after the `pnpm publish -r` command. This ensures the proper git tags are also created, allowing for the GitHub releases to be published.
A few commands were still checking on `--cwd` explicitly, which is incorrect since the entrypoint file already handles the directory change.
The new `client.cwd` property is a helper to make writing tests easier. Tests no longer need to `chdir()` explicitly and then revert afterwards.
This reverts commit 1e47bbf32f.
`changeset publish` also creates git tags, whereas `pnpm publish -r` does not. This causes the GitHub Releases to not be created.
Right now, we can't detect API routes correctly if `pageExtensions` is set:
> WARNING: Unable to find source file for page xxxx with extensions: js, jsx, ts, tsx, this can cause functions config from `vercel.json` to not be applied
We added appDir support in https://github.com/vercel/vercel/pull/9811 so that users can customize `memory`/`maxDuration` for routes in appDir.
But since RSC is enabled by default in Next.js 13, `vercel build` still reports some warning messages, such as:
```json
"functions": {
"app/**/*": {
"maxDuration": 5,
"memory": 512
}
}
```
```
WARNING: Unable to find source file for page hello.js with extensions: ts, tsx, js, jsx, md, mdx, this can cause functions config from `vercel.json` to not be applied
WARNING: Unable to find source file for page index.js with extensions: ts, tsx, js, jsx, md, mdx, this can cause functions config from `vercel.json` to not be applied
```
To suppress these errors and properly apply `functions` setting to those routes, updating the current detection logic to also search `page.${ext}` files.
This PR removes dependency on the deprecated `lastRollbackTarget` project property and adopts many of the code conventions used in `vc promote`.
Important! Please merge #9984 first!
Hey team,
I had an error this morning when trying to link my repo using the CLI
Seems like a combination of `: any` and a recent refacto introduced an issue here.
~- Removed all `any` that were hiding the error~
- Correctly pass the URL already parsed
~- Removed the second useless parsing~
~- Added missing `--help` flag~
~I noticed you never specify them and Typescript screams because of that, not sure if on purpose and how you make the compilation pass with this error. Don't hesitate to tell me.~
The fix could be improved by using `arg.Result<THE_ACTUAL_TYPE>` but that would require to store the dictionnary of flags somewhere else and also create an external type. This is already better so...
---
NB:
I had multiple issues while cloning this repo
- pnpm bootstrap does not work
- missing `constants.ts` file that is not explained in the Contributing guidelines
- maybe due to bootstrap not working, almost nothing else worked and the tests too.
Some of these packages got out of sync at some point, causing duplicate
/ older copies to be installed. Additionally, the `@vercel-internal`
packages should have "version" fields.
Attempting to fix these
[warnings](https://github.com/vercel/vercel/actions/runs/5048844603/jobs/9057538600)
during release:
```
Package "examples" must depend on the current version of "@vercel/frameworks": "1.4.2" vs "1.3.0"
Package "@vercel-internals/constants" must depend on the current version of "@vercel/build-utils": "6.7.3" vs "6.3.2"
Package "@vercel-internals/constants" must depend on the current version of "@vercel/routing-utils": "2.2.1" vs "2.1.10"
Package "@vercel-internals/constants" must depend on the current version of "@vercel-internals/tsconfig": "undefined" vs "*"
Package "@vercel-internals/get-package-json" must depend on the current version of "@vercel-internals/tsconfig": "undefined" vs "*"
Package "@vercel-internals/types" must depend on the current version of "@vercel-internals/constants": "undefined" vs "*"
Package "@vercel-internals/types" must depend on the current version of "@vercel/build-utils": "6.7.3" vs "6.3.2"
Package "@vercel-internals/types" must depend on the current version of "@vercel/routing-utils": "2.2.1" vs "2.1.10"
Package "@vercel-internals/types" must depend on the current version of "@vercel-internals/tsconfig": "undefined" vs "*"
Package "vercel" must depend on the current version of "@vercel-internals/constants": "undefined" vs "*"
Package "vercel" must depend on the current version of "@vercel-internals/get-package-json": "undefined" vs "*"
Package "vercel" must depend on the current version of "@vercel-internals/types": "undefined" vs "*"
Package "@vercel/node" must depend on the current version of "@vercel/error-utils": "1.0.10" vs "1.0.8"
```
`vc deploy` ignores `.env.local`. To make sure we don't inadvertently
push people's secrets to source control, have all environment pulls
default to writing to `.env.local`.
Removes the unused `--platform-version` flag from the common args.
Technically this is a breaking change, so we should probably hold off on merging until we plan to do a major version bump.
The logic to retrieve the latest release was not working correctly, so use the `getLatestRelease()` function instead of assuming that `release[0]` is tagged as the latest.
In a Next.js app, if you have Node.js Functions in both `api` and `pages/api`, you'll get a warning about moving those `api` functions into `pages/api`. This does specify Node.js Functions already, but a user was confused and tried to move their non-Node.js functions into `pages/api` as well.
This PR tries to make it clearer that you can do both. Note that this still requires a non-ideal local dev setup where you:
- update next config to fall back to the `vc dev` port for `api` handlers
- run `next dev` for the Next.js app on one port
- run `vc dev` for the top-level `api` Functions on another port
---
Example repo: https://github.com/rexfordessilfie/vercel-api-languages
Adding a new `--repo` flag to `vc link` which is a new linking style to
link to a Git URL rather then directly to a single Vercel Project. This
allows for multiple Projects to be linked simultaneously, which is
useful for monorepo setups.
Utilization of this new linking style in other commands will be done in
a follow-up PR.
There is an issue where you can interrupt a gatsby project build and the temporary files are not cleaned up. If you try to build again, it will get stuck in an infinite loop.
This PR adds an exit hook to make sure the cleanup happens.
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## vercel@29.3.4
### Patch Changes
- Updated dependencies
\[[`67e556bc8`](67e556bc80),
[`ba10fb4dd`](ba10fb4dd4)]:
- @vercel/remix-builder@1.8.9
- @vercel/next@3.8.4
## @vercel/next@3.8.4
### Patch Changes
- Update handling for react prebundled flag
([#9974](https://github.com/vercel/vercel/pull/9974))
## @vercel/remix-builder@1.8.9
### Patch Changes
- Upgrade `@remix-run/dev` fork to v1.16.1
([#9971](https://github.com/vercel/vercel/pull/9971))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This ensures we properly set the prebundled react flag conditionally for
app and pages ensuring they are kept separate when bundling.
x-ref: https://github.com/vercel/next.js/issues/49169
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.
# Releases
## vercel@29.3.3
### Patch Changes
- Updated dependencies
\[[`6c6f3ce9d`](6c6f3ce9d2)]:
- @vercel/next@3.8.3
## @vercel/next@3.8.3
### Patch Changes
- Ensure un-necessary rsc routes are not added
([#9963](https://github.com/vercel/vercel/pull/9963))
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
It's possible that changesets will promote a release to latest that is
not the Vercel CLI release. This script ensures that a `vercel@` release
is always the latest after a publish happens.
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
# Releases
## vercel@29.2.1
### Patch Changes
- Updated dependencies \[[`6d5983eaa`](6d5983eaae)]:
- @vercel/remix-builder@1.8.8
## @vercel/remix-builder@1.8.8
### Patch Changes
- Upgrade `@remix-run/dev` to v1.16.0-patch.1 to fix erroneous "not found in your node_modules" warning ([#9930](https://github.com/vercel/vercel/pull/9930))
Partial revert of #9932, since apparently [that didn't
work](https://github.com/vercel/vercel/actions/runs/4941266637/jobs/8833725828).
We can investigate that more later, but this gets it working again
properly at least.
Also use Svelte's changelog generator, since it includes the PR numbers
which Sean wanted.
* Have changesets create the release PR as "Vercel Bot", so that the
tests run.
* Remove the `CHANGELOG.md` files. They are redundant with the GH
Releases which contain the same information.
`changesets` will improve our release workflow, since we will no longer need to manually curate and publish the changelog and GitHub Release. Instead, you simply merge the publish PR that the changesets GH action maintains as we push commits to `main`.
# Vercel CLI Extensions
Adds a new mechanism to add additional sub-commands to Vercel CLI, inspired by how Git handles sub-commands:
* Extensions are standalone executables that Vercel CLI will spawn as a child process.
* The name of the executable must begin with `vercel-`. For example, to add a sub-command called `vercel example`, there should exist an executable called `vercel-example`.
* The executable can either be a npm package with a `"bin"` entry installed into the local project's workspace, or be globally available in the `$PATH`.
* Extensions can access the [Vercel REST API](https://vercel.com/docs/rest-api), pre-authenticated, by utilizing the `VERCEL_API` env var. Vercel CLI spawns a local HTTP server that adds the `Authorization` header and then proxies to the Vercel REST API.
## Environment Variables
A few environment variables which provide features and context to the extension:
| Name | Description |
| ----------- | ----------- |
| `VERCEL_API` | HTTP URL to access the pre-authenticated Vercel API. |
| `VERCEL_TEAM_ID` | Provided when the currently selected scope is a Team. |
| `VERCEL_DEBUG` | Provided when the `--debug` flag is used. The command _may_ output additional debug logging. |
| `VERCEL_HELP` | Provided when the `--help` flag is used. The command _should_ print the help output and then end with exit code **2**. |
## Example
```bash
#!/usr/bin/env bash
set -euo pipefail
echo Hi, from a Vercel CLI Extension!
user="$(curl -s "$VERCEL_API/v2/user" | jq -r .user.username)"
echo "Logged in as: $user"
```
Usage:
```
$ vc example
Vercel CLI 28.18.5
Hi, from a Vercel CLI Extension!
Logged in as: tootallnate
```
When getting help output for the default command `vc --help`, you get a list of commands. When you specify the `deploy` command with `vc deploy --help`, you get the same list of commands.
This PR makes a distinction between an explicit `deploy` command and a default one for the purposes of help output.
Should show CLI help:
- `vc -h`
- `vc --help`
- `vc help`
Should show `deploy` command help:
- `vc deploy -h`
- `vc deploy --help`
- `vc help deploy`
When looping over the response headers returned by `node-fetch`, it will join `set-cookie` header value into a single string. The whatwg calls for a `headers.getSetCookie()` function to handle the `set-cookie` special case, but `node-fetch@2.x` doesn't support it.
As a workaround, we need to grab the raw `set-cookie` header value.
The `WebSocket` constructor exposed by `undici` is not working against some db connections.
That can be considered kind of expected since `undici` docs is saying it's experimental.
We're working into isolate the issue and report at `undici` repository, but for now, let's just use `ws` for all the node versions.
Currently, any warnings logged when calling `readConfig()` are emitted in build logs _three times_:
1. When initially reading the config before executing the Build Command
2. When the Build Command is executed (`remix build` reads the config)
3. After the build, in the `prepareCache()` function
For the callsites that we are in control of (`1.` and `3.`), we should suppress those warnings and only allow the standard warnings when invoking `remix build` to be emitted to the build logs.
`ignoreRuntimes: ['@vercel/node']` will also disable root-level middleware, which is not intended. So ensure that middleware still work, even for frameworks that have this `ignoreRuntimes` configuration enabled (Remix, RedwoodJS).
Adds `home` and `global` as supported values for `regions` when coming
from Next.js. We'll port these to the build output API at a later time.
Related Next.js changes: https://github.com/vercel/next.js/pull/48959
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
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>
When `@vercel/node` was created 5 or so years ago, Node.js didn't support ESM out of the box. So to create a zero configuration experience, babel was introduce to compile the authored ESM into the runtime CJS.
Today, Node.js supports ESM but you have to opt in using `type: module` in package.json or the `.mjs` file extension.
Indeed `@vercel/node` detects ESM and skips babel compilation. However, there is a case where the source code is ESM and a dependency supports both ESM and CJS via `imports` in package.json. This case will break because `@vercel/nft` traces the source file as ESM and assumes the dependency will be resolved as ESM too. But after `@vercel/nft` traces the source file, `@vercel/node` will compile to CJS and thus the trace will be incorrect and fail at runtime.
So this PR adds a warning when babel compiles ESM to CJS because it is no longer expected in 2023.
Currently, `functions` property (i.e., `memory` and `maxDuration`) are
not supported in appDir routes. This PR attempts to add support.
---------
Co-authored-by: Chris Barber <chris.barber@vercel.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
We want to keep the currently unused `runtime: "nodejs"` value clear for future use. This PR effectively makes any unrecognized value fail the build. If the value is "nodejs" specifically, a direct error is thrown suggesting they remove the value.
Only a handful of projects set this value currently. We're reaching out to them to let them know that this value is not currently supported and that they should remove it. Then, we should deploy this PR so that anyone else using this value will know to remove it.
It doesn't make sense to have `--target` as a global argument, because not all subcommands utilize this flag (actually only `vc deploy` does, and it's even deprecated).
This is technically a breaking change (though risk of someone using this flag on non-`vc deploy` is very unlikely), so we may want to hold off on merging this until we're ready to do a major version bump.
Right now, @Kikobeats is a required approver on `packages/node`. This change allows them to approve changes to the package without being absolutely required.
Log state validation errors, because they can be user error.
Example:
```
error "gatsby-node.js" threw an error while running the onPostBuild lifecycle:
Gatsby state validation failed:
- Expected boolean, got string ("true") at path "/redirects/0/isPermanent"
Please check your Gatsby configuration files, or file an issue at https://vercel.com/help#issues
3 |
4 | export const onPostBuild = async ({ store }: { store: any }) => {
> 5 | await generateVercelBuildOutputAPI3Output({
| ^
6 | // validated by `pluginOptionSchema`
7 | gatsbyStoreState: store.getState(),
8 | });
```
This enables the CLI to pass locally detected git meta data even when there is no available remote. It requires a corresponding internal change, which is blocking the e2e tests.
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>
The next-local e2e tests where split between middleware (fast) and all other (slow) tests. This meant there was not a good balance of amount of time spent across these test files, making overall test run times as slow as "all other tests" running.
This PR rebalances the split of tests across 2 files. The new run time is ~9-10m.
`@vercel/node` uses `ncc` to bundle the `index.js` spawns the dev server entrypoint which does not bundle the required dependencies, thus `path-to-regexp` and `ts-morph` must be moved from dev dependencies to dependencies.
Fixes#9735.
There's a need to allow `vc deploy` to not block and not wait for the deployment to finish, yet return the URL.
```
$ vc deploy --no-wait
Vercel CLI 28.18.5
🔍 Inspect: https://vercel.com/chrisbarber/next13fun/L8X4oxp5LGcmy51yVptXwMK7n4wt [1s]
📝 Note: Deployment is still processing...
✅ Production: https://next13fun-kecpx6za2-chrisbarber.vercel.app [1s]
```
Normally this deployment takes around 30 seconds, but the `--no-wait` flag causes the command to exit in less than 2 seconds.
The next step is to add the ability for `vc inspect` to wait as well as specify the maximum time to wait (defaults to 3 minutes, same as `vc rollback`).
```
$ vc inspect --wait --timeout 1m https://next13fun-kecpx6za2-chrisbarber.vercel.app
Vercel CLI 28.18.5
> Fetched deployment "next13fun-ov2r4pvdz-chrisbarber.vercel.app" in chrisbarber [23s]
General
id dpl_9VUuV23EGeoqWf7akEeL8rP1c8cb
name next13fun
status ● Ready
url https://next13fun-ov2r4pvdz-chrisbarber.vercel.app
created Thu Apr 13 2023 12:25:07 GMT-0500 (Central Daylight Time) [24s ago]
<snip>
```
Also added the ability to pipe the URL into `vc inspect`:
```
echo https://next13fun-ov2r4pvdz-chrisbarber.vercel.app | vc inspect
```
Combined, it allows us to support cool things like:
```
$ vc inspect $(vc deploy --prod --no-wait) --wait
```
- Creates new internals package, `@vercel-internals/constants`
- Refactors the `enum`s from `@vercel-internals/types` into `as const` objects, and moves them to `@vercel-intenrals/constants`
- Updates all relevant code within `packages/cli`, including `@vercel-internals/types` imports to be `import type`
This PR fixes a few issues related to `vc dev`.
1. Create a default `go.work` file in the cache dir when building the `vercel-dev-server-go` executable
2. Copy the existing `go.mod` file into the cache dir and update any "replace" relative paths
3. Split the "build" logic into separate functions for the legacy "main" package build and the `go.mod` build
Additionally, it fixes:
1. `vc build`: pass in `build.env` from `vercel.json`
2. Fix several tests to work with `vc dev` and `vc build`
Linear: https://linear.app/vercel/issue/VCCLI-638/vc-dev-go-builder-cant-resolve-workspace-dependencies
The user that reported the issue has tested this build and seems to fix their use case: https://github.com/vercel/vercel/issues/9393#issuecomment-1490726785.
Fixes an edge case in `parseRepoUrl()` when there is a `.com` in the repo name. The code was hard to refactor in its previous form so I refactored it to be simpler as well.
Before, we were stripping off only the hostname portion of `assetPrefix`, so any pathname was still being "handled" by the plugin.
Instead, we should be ignoring the `assetPrefix` entirely, so that these two configurations are treated differently:
* `{ assetPrefix: 'http://example.com', pathPrefix: '/foo' }` - Gatsby project is served from `/foo`
* `{ assetPrefix: 'http://example.com/foo', pathPrefix: undefined }` - Gatsby project is served from the root `/`
Currently, both configuration behave as the first version listed above. This change makes it so they can behave differently, specifically for some proxy configurations.
In both cases, the generated HTML contains the full URL `http://example.com/foo/*` for JS/CSS/etc. assets
Adds a new package under `scripts/internal-dependency-trace` that can be used to generate a rendering of any internal file dependency graph.
Default configured to generate the directed dependency graph of `packages/cli/src/index.ts`
This demo now showcases:
- `/` - A static page (pre-rendered)
- `/ssr` - A page that uses server-side rendering (through Vercel Edge Functions)
- `/ssr-with-swr-caching` - Similar to the previous page, but also caches the response on the Vercel Edge Network using `cache-control` headers
- `/edge.json` - An Astro API Endpoint that returns JSON data using Vercel Edge Functions
The new example has been deployed to https://astro.vercel.app.
Adds a new Route property called `isInternal` that indicates whether or not this is a project route or a Vercel platform route. Routes with this flag will be hidden from project-specific lists of routes to avoid confusion.
Verified on staging.
Minimatch 3.0.4 has a [ReDoS
vulnerability](https://security.snyk.io/vuln/SNYK-JS-MINIMATCH-3050818).
While not likely to be an issue for the packages that use it here, a
simple version bump should prevent the issue and reduce vulnerability
noise on audits. 3.1.2 is the latest version within the 3.x range, so
prevents breaking changes.
Follow-up to #9696. Ensures that all packages in this repository have
the correct "license" field in their respective `package.json` files set
to "Apache-2.0", to match the `LICENSE` file at the root of the
repository.
The `LICENSE` file the authoritative source, so the "MIT" value was
incorrect. This change corrects the previous values and is not
considered a relicensing.
Extracts the logic from `pkg.ts` into a new utility function
`getPackageJSON` from `@vercel-internals/utils`.
---------
Co-authored-by: Nathan Rajlich <n@n8.io>
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.
Welcome to the grand splitting of CLI integration tests:
- replaced `test-cli` test suite with `test-e2e`
- made some small fixes along the way
- split integration tests into 3 files
- moved shared logic to `packages/cli/test/helpers/*`
- simplified `_execa` / `execa` / `execute` usage into `execCli` and `exec`
- simplified arguments required to make these work
- defaulted `execCLI` to set `NO_COLOR=1` to make assertions simpler in tests that aren't testing color/emoji support
- expanded functionality of `formatOutput` to handle error states
- centralized temp dir handling and cleanup
- enhanced `waitForPrompt` to:
- more clearly show what it was waiting for
- support waiting for regex, string, or a function that returns a boolean
- show what was the most recent thing it saw
- end early if the process it's monitoring exits
- removed some test pollution where unnecessary, shifted some into `beforeAll`
- renamed unit tests helper from `setupFixture` to `setupUnitFixture` to avoid confusion with the new shared helper `setupE2EFixture`
Some of this could be pulled out into a separate PR, but the feedback cycle is a slog, which this PR is helping to address. I'd be happy to discuss what could be pulled out, but I'd also be happy to get the whole thing through.
---
Wait for prompt failures:
<img width="939" alt="CleanShot 2023-03-27 at 10 24 21@2x" src="https://user-images.githubusercontent.com/41545/227987773-a3582549-32f9-4131-8a35-7be7cc265b66.png">
---
Current Timing:
```
Tests / test-e2e (vercel, 1, ubuntu-latest) (pull_request) Successful in 3m
Tests / test-e2e (vercel, 2, ubuntu-latest) (pull_request) Successful in 8m
Tests / test-e2e (vercel, 3, ubuntu-latest) (pull_request) Successful in 8m
```
---
Before merge, I'll mark the original `CLI` integration test suite as no longer required.
The `handleRequest()` function has been moved to the `@vercel/remix` package, so we can deprecate `@vercel/remix-entry-server` entirely and install `@vercel/remix` in the project instead, when there is no `app/entry.server.tsx` file defined in the project already.
Some condition in the system caused `BUILD_UTILS_SPAWN_1` errors to be thrown for failed deployments. The error handling logic wasn't handling this properly, causing the error message to never show up in the output.
```
Error: Unexpected error. Please try again later. ()
```
This PR fixes a handful of Go builder issues all related to the selected Golang version being used to build the function:
- `go.mod` version ignored for `vc build` and `vc dev`, uses system `PATH` version only
- `vc dev` fails if `go.mod` does not exist
- If the analyze bin doesn’t exist, downloads golang into `.vercel/cache/golang` instead of a global shared dir
- When running `vc dev`, doesn’t reuse go build code/common settings
- go tidy fails when `go.mod` set to 1.19 or 1.20, but 1.18 or older is installed
- `vc build` builds wrong arch on Apple Silicon/arm64
- `vc build` on Windows doesn't properly resolve "builds" in `vercel.json` due to posix separator issue
- `vc build` on Windows fails with `package <pkg/name> is not in GOROOT` due to posix separator issue
- Removed `actions/setup-go` from all test workflows
I added a test that tests the `go tidy` issue.
As reported https://github.com/vercel/vercel/discussions/9648, `vc build` does not honor the `--local-config <file>` option.
`vc build` will only load the `vercel.json` (or `now.json`) in the `workPath` which is based on the `rootDirctory`.
If `--local-config` is specified in the command line arguments, then it should take precedence.
When creating the `./vercel/output/static` dir...
**Moving the `public` dir** is what currently happens. This causes Gatsby to believe that the build was not complete:
> info We've detected that the Gatsby cache is incomplete (the .cache directory exists but the public directory does not). As a precaution, we're deleting your site's cache to ensure there's no stale data.
**Copying the `public` dir** is not an option because it can cause a build to run out of space.
**Symlinking the `public` dir** would work, but it would require more changes throughout the system to make sure the symlink was followed properly.
**Hard Linking the `public` dir's files** is the best option. This PR links the directories instead of moving them. We did look for a library that already does the `hardlinkFileTree` thing, but couldn't find one.
---
**Testing**
This was manually tested with real deployments.
---
* paired with @TooTallNate
* [user report](https://github.com/vercel/vercel/issues/9452#issuecomment-1432858615)
This PR is some cleanup before splitting python e2e tests.
Changes:
- use `probes.json`
- use `/api` autodetection instead of `builds` array
---
I was also trying to figure out why these tests are so much faster when run locally (293s) vs. CI (1099s). I encountered issues trying to view the build logs for the deployments that are made.
Remix v1.14.0 added support for having no `app/entry.server.tsx`/`app/entry.client.tsx` files in a project (there are default versions bundled into `@remix-run/dev`). Projects configured like this are currently failing because we symlink our forked version of the `remix` CLI into the project, so it cannot resolve the necessary modules at build time.
To solve this, instead of relying on the default versions of these files in `@remix-run/dev` package, we'll include our own versions in `@vercel/remix`, and physically copy them into the project dir. This way, the modules used will be properly resolved relative to the project's own `node_modules` dir.
Our default version of `app/entry.server.tsx` is also slightly different then upstream one, because it uses `@vercel/remix-entry-server` to enable isomorphic React streaming on both Node + Edge runtimes. Because of this, if that dependency is not present, then we'll automatically install the dependency at build-time.
In a previous PR (#9615) the unit tests were moved to separate jobs in
the `test.yml` workflow. So we can now change the `test-unit.yml`
workflow to simply be `test-lint.yml` to avoid redundancy.
I also checked to see if this would affect code coverage but it turns
out codecov was [disabled a long time
ago](https://app.codecov.io/gh/vercel/vercel).
- Creates `@vercel-internals/tsconfig`
- Changes `@vercel-internals/types` to depend on `@vercel-intenrals/tsconfig`
- Creates `@vercel-internals/utils`
Moving these to another PR:
- ~Moves all top level util files from `@vercel/cli` to `@vercel-internals/utils`~
- ~Updates all relevant imports within `@vercel/cli` to use `@vercel-internals/utils`~
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.
Next.js will pass the original middleware matching routes through to the middleware manifest once https://github.com/vercel/next.js/pull/46753 lands. This PR will take those original values and put them in the middleware route `middlewareRawSrc` property.
NOTE: The tests will need to be updated once the Next.js version is updated in the fixtures.
The "gatsby" dependency is large and relies on native packages ("sharp" specifically, which are error prone because it attempts to download a precompiled binary, of which the CDN has been down before causing us to not be able to merge anything).
The package is only used for TypeScript types, and we've decided that including the package only for those types is not worth the trouble. The existing JSON schemas already validate at runtime that the Gatsby redux store provides the values that we depend on.
`ajv` was ditched in favor of TypeBox types, which provide both JSON Schema and validation using a simpler syntax.
In Remix routes, you can [use bracket notation to escape the filesystem routing behavior](https://remix.run/docs/en/1.14.0/file-conventions/routes-files#escaping-special-characters). For example `app/routes/receipt[.]pdf.tsx` would be available at path `/receipt.pdf` (whereas, unescaped, it would be at `/receipt/pdf`).
This adds an e2e test for that behavior.
Move the try/catch block to immediately after the symlink call, so that if reading the `remix.config.js` file throws an error or if there's an error parsing the `export const config` in a route, the catch block will clean up after itself properly.
I recommend reviewing with [whitespace changes hidden](https://github.com/vercel/vercel/pull/9595/files?w=1).
Changes the way that routes with optional params are stored on Vercel to not use `?` in the name, because it's not possible to have a route destination with a `?` that's pointing to a function.
So instead of the function with a name such as `:lang?`, it will be stored on Vercel with a name like `(:lang)`, which can be routed to.
Show a more helpful message instead of showing a cryptic error messsage:
> Error: ENOENT: no such file or directory, copyfile
'/var/task/node_modules/@vercel/remix/server-node.mjs' ->
'/vercel/path0/packages/web/build/server-node.mjs'
This is probably due to a bad user configuration (i.e. with Turbo), but
tell them to contact support anyways in case there is a different cause
that we would need to address.
Apply the `regions` configuration (for both Edge and Node) and `memory`/`maxDuration` (only for Node) in a page's static config export, i.e.
```js
export const config = { runtime: 'edge', regions: ['iad1'] }
// or for Node
export const config = { runtime: 'nodejs', regions: ['iad1'], maxDuration: 5, memory: 3008 }
```
Similar to `runtime`, these config values can be inherited from a parent layout route to apply to all sub-routes. Routes with common config settings get placed into a common server bundle, meaning that there may now be more than 2 functions created (previously was one Edge, one Node), allowing for more granularity between the server build bundles.
Utilize the [`serverBundles`](https://github.com/remix-run/remix/pull/5479) config option to generate two server bundle builds. One contains only the routes that should run in Node.js, and the other contains only the routes that should run in the Edge runtime. In the future we could update this configuration to generate more than two bundles to be more granular and allow for infinite scalability.
Because the `serverBundles` PR is not yet merged, this PR introduces usage of a forked version of `@remix-run/dev` which incorporates our changes. Hopefully usage of a fork is temporary, but it gets us unblocked for now.
Makes it easier to test fixtures directly via CLI deployments.
Coincidentally, this also revealed that auto-detection of Remix apps wasn't working correctly if there's a `remix.config.mjs` file. So `@vercel/frameworks` is updated to account for that case as well.
Fixes an edge-case error when changing the version of Remix and then making a deployment to Vercel when there is already an existing build cache:
> Error: EEXIST: file already exists, symlink '../.pnpm/@remix-run+server-runtime@1.5.0_biqbaboplfbrettd7655fr4n2y/node_modules/@remix-run/server-runtime' -> '/vercel/path0/node_modules/@remix-run/server-runtime'
This would happen because the symlink was created in a previous run, but no longer points to a valid path because it's a different version. To fix we'll delete the previous symlink when the target value does not match.
Adds support for bundling properly the dependencies used by the experimental instrumentation hook file, `instrumentation.js`, by adding the generated nft file to the list of server deps
fixes NEXT-631
There's [a PR](https://github.com/remix-run/remix/pull/5537) opened on
Remix to add an Edge compatible entrypoint to `@remix-run/vercel`. This
is only really needed specifically for projects that have a custom
server.js entrypoint file, which is not strictly necessary anymore, but
there are some edge cases where a project might still want to have one.
So this PR is necessary for those kinds of projects to be able to use
Edge runtime.
Even when they merge the PR, it would be good to leave this injection
code around for some time to continue support for older
`@remix-run/vercel` versions in existing projects.
Updates the `responseHeaders` probe checks to properly test for multiple headers with the same name.
Previously the probes were using `headers.get()` which concats multiple headers into a single string, which results in the test not really checking if there are in fact multiple headers with the same name. Using `headers.raw()` allows us to properly test for that.
A couple of Python tests that were already checking for multiple `set-cookie` headers needed to be updated to match the full value, since the check now properly validates the full string match of each header (before it was basically just doing a `string.includes()` check).
This is a precursor for https://github.com/vercel/vercel/pull/9533.
If for some reason the `get-latest-worker.js` fails to get the dist-tags, it doesn't check the status code and proceeds to `JSON.parse()` the response. If for example npm returns 401 Unauthorized, you get a cryptic JSON parse error message.
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
In a Turborepo setup, there was this in the `remix.config.js` file:
```js
watchPaths: [require.resolve("ui")],
```
Since we attempt to `require()` the `remix.config.js` file in order to
determine whether or not it is using ESM syntax, this would fail since
the require happens before the Build Command is executed.
To fix, treat any non `ERR_REQUIRE_ESM` error as CJS, instead of
re-throwing the error. If there really is an issue with importing the
config, then that'll happen right after when `remix build` is doing it.
When the project defines a custom `server.js` file in `remix.config.js`,
then don't override that with the bundled
`server-node.mjs`/`server-edge.mjs` file. This allows for a custom
`getLoadContext()` function to remain supported.
In order for Edge runtime to be supported, a [companion
PR](https://github.com/remix-run/remix/pull/5537) for
`@remix-run/vercel` adapter has been created with a dedicated entrypoint
for when Edge runtime is being used. In order to support Edge on
previous versions of the adapter, we may end up patching the package to
enable support, but that will happen in a follow-up PR.
Related to https://github.com/orgs/vercel/discussions/1596.
---------
Co-authored-by: Sean Massa <EndangeredMassa@gmail.com>
Make it so that the `export const config = { runtime }` value is "inherited" from a parent route, if it is defined.
For example, "edge" can be defined in `app/root.tsx`, and so all routes will use the Edge runtime by default, unless `"runtime": "nodejs"` is used more specifically in a route deeper in the route hierarchy.
`vc remove --safe <project>` has a unique code path that queries all deployments by project id. This function calls v4 deployments endpoint and returns the legacy deployment structure.
The problem is the `vc remove` command relies on the new `Deployment` structure defined by the v13 get deployment endpoint.
I've updated the `getDeploymentsByProjectId()` function to transform the legacy structure into the current one.
Fixes#9321
Linear: https://linear.app/vercel/issue/VCCLI-538/vc-rm-project-safe-is-not-working
After many hours of debugging, I tracked down that having an old Node
version (eg 14.x) listed in your Vercel project settings can result in
the build step failing with a confusing and unhelpful error message
"`@vercel/next` No Serverless Pages Built". Note that this is a case
where it "can" cause it to fail, including with NextJS 13.1.6 and Vercel
CLI 28.16.2, but it is not guaranteed to fail. I have six NextJS
projects. They have identical next.config.js, tsconfig.json,
eslintrc.js, and .gitignore files, and other than a few seemingly
non-critical dependencies they have identical package.json files. Four
of the six consistently built and deployed in the cloud without issue.
Two consistently failed to build in the cloud. All built successfully
locally including using vercel build locally, and all would vercel
deploy --prebuilt successfully. Switching all the vercel cloud project
settings from Node 14.x to Node 18.x enabled all the projects to build
and deploy successfully in the vercel cloud without needing local vercel
build and local vercel deploy --prebuilt steps.
---------
Co-authored-by: Steven <steven@ceriously.com>
This PR changes the fallback headers that relate to RSC to the defaults that Next.js currently uses. Also, it sets the initial `vary` header to all prerendered routes when RSC is enabled (`routesManifest?.rsc`), even for the pages directory.
That's because although the pages directory won't return any RSC payload, it can still be used in a project that contains app routes. When the app route requests a page route for RSC data, it's important for the browser to not accidentally cache that result hence we need the `vary` header to set there as well.
More related discussions can be found [here](https://linear.app/vercel/issue/NEXT-382/add-vary-rsc-etc-header-to-all-responses-to-ensure-browser-caching).
In order to have Next.js Lambdas show their operation types more specifically in the build output in the dashboard, the builder needs to return the Lambdas with `operationType` set to the appropriate value.
This PR adds those values. This allows the Richer Deployment Outputs to show the different types of serverless functions:
<img width="228" alt="Screenshot 2023-02-03 at 3 49 42 PM" src="https://user-images.githubusercontent.com/41545/216717479-d02fbd4a-fa62-479d-8b65-bd77fdcdb26c.png">
Missed this occurrence so it still prevents the upload of serverless
functions that have a mem value that is not dividable by 64.
Should be the last place before we can ship the documentation update.
#### Related PRs
- #9440
Co-authored-by: Steven <steven@ceriously.com>
When WEBrick receives `HEAD` requests it discards the body (i.e.
`req.body.nil? => true`), this causes Vercel to throw a
`BODY_NOT_A_STRING_FROM_FUNCTION` since it is expecting the serverless
function to respond with a string in the body.
---------
Co-authored-by: Nathan Rajlich <n@n8.io>
Co-authored-by: Steven <steven@ceriously.com>
This PR changes the way cron jobs are being created in the build output
API. This is my first time contributing here. If you see something
unusual, let me know.
✅ Good for review
Our goal is to:
- Allow creating cron jobs via the `crons` property of `vercel.json` for
end users
- Allow framework authors to create cron jobs on Vercel via the `crons`
property of the Build Output API configuration
---
As you can see, we removed the previous implementation where cron jobs
could be configured at the function code level (export const cron = ""),
on top of vercel.json `functions` property. Here's why:
- All frameworks would have to implement the configure at the function
code level
- Not all frameworks can easily map a path to a specific function
(example: SvelteKit) and would have to bail on bundling functions inside
the same lambda
- Configuring a path + scheduler provides a better mapping of what cron
jobs are as of today: API routes on a schedule and not functions on a
schedule
- Dynamic routes Cron Jobs will be supported:
/api/crons/sync-slack-team/230
- Query parameters will be supported support:
/api/crons/sync-slack-team/230?secret=32k13l2k13lk21 (= securing cron
jobs v0)
- 100% frameworks compatibility from day one
Next.js and other frameworks may choose to implement their own cron jobs
feature that will then need to be configured through the `crons`
property of `config.json` (build output API).
cc @timneutkens @Rich-Harris
Internal thread:
https://vercel.slack.com/archives/C04DWF5HB6K/p1676366892714349
Adds framework to Lambda and edge build outputs so that we can distinguish which framework they originated from when certain features should be applied to specific frameworks.
This PR adds framework to the outputs. Part 1: https://github.com/vercel/vercel/pull/9448
ticket: ED-131
x-ref: [slack channel](https://vercel.slack.com/archives/C042LHPJ1NX)
`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.
2023-02-14 22:59:52 +00:00
1273 changed files with 130667 additions and 91699 deletions
> **Note**: For discussions not related to Vercel CLI or Runtimes, please visit the [Vercel Community](https://github.com/orgs/vercel/discussions/categories/help)
> **Note**: For discussions not related to Vercel CLI or Runtimes, please visit the [Vercel Community](https://github.com/orgs/vercel/discussions/categories/ideas)
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:
Vercel is the platform for frontend developers, providing the speed and reliability innovators need to create at the moment of inspiration.
We enable teams to iterate quickly anddevelop, preview, and shipdelightful user experiences. Vercel has zero-configuration support for 35+ frontend frameworks and integrates with your headless content, commerce, or database of choice.
Vercel's frontend cloud gives developers frameworks, workflows, and infrastructure to build a faster, more personalized web.
You ran `vercel dev` inside a project that contains a `vercel.json` file with `env` or `build.env` properties that use [Vercel Secrets](https://vercel.com/docs/concepts/projects/environment-variables).
In order to use environment variables in your project locally that have values defined using the Vercel Secrets format (e.g. `@my-secret-value`), you will need to provide the value as an environment variable using a `.env`.
In order to use environment variables in your project locally that have values defined using the Vercel Secrets format (e.g. `@my-secret-value`), you will need to provide the value as an environment variable using a `.env.local`.
We require this to ensure your app works as you intend it to, in the development environment, and to provide you with a way to mirror or separate private environment variables within your applications, for example when connecting to a database.
@@ -12,11 +12,11 @@ Read below for how to address this error.
#### Possible Ways to Fix It
The error message will list environment variables that are required and which file they are required to be included in `.env`.
The error message will list environment variables that are required and which file they are required to be included in `.env.local`.
If the file does not exist yet, please create the file that the error message mentions and insert the missing environment variable into it.
For example, if the error message shows that the environment variable `TEST` is missing from `.env`, then the `.env` file should look like this:
For example, if the error message shows that the environment variable `TEST` is missing from `.env.local`, then the `.env.local` file should look like this:
@@ -14,7 +14,9 @@ In order to create the smallest possible lambdas Next.js has to be configured to
npm install next --save
```
2.Add the `now-build` script to your `package.json`
2.Check [Node.js Version](https://vercel.link/node-version) in your Project Settings. Using an old or incompatible version of Node.js can cause the Build Step to fail with this error message.
3. Add the `now-build` script to your `package.json` [deprecated]
```json
{
@@ -24,7 +26,7 @@ npm install next --save
}
```
3. Add `target: 'serverless'` to `next.config.js` [deprecated]
4. Add `target: 'serverless'` to `next.config.js` [deprecated]
```js
module.exports={
@@ -33,9 +35,9 @@ module.exports = {
};
```
4. Remove `distDir` from `next.config.js` as `@vercel/next` can't parse this file and expects your build output at `/.next`
5. Remove `distDir` from `next.config.js` as `@vercel/next` can't parse this file and expects your build output at `/.next`
5. Optionally make sure the `"src"` in `"builds"` points to your application `package.json`
6. Optionally make sure the `"src"` in `"builds"` points to your application `package.json`
This directory is a brief example of an [Astro](https://astro.build/) site that can be deployed to Vercel with zero configuration.
This directory is a brief example of an [Astro](https://astro.build/) site that can be deployed to Vercel with zero configuration. This demo showcases:
-`/` - A static page (pre-rendered)
-`/ssr` - A page that uses server-side rendering (through Vercel Edge Functions)
-`/ssr-with-swr-caching` - Similar to the previous page, but also caches the response on the Vercel Edge Network using `cache-control` headers
-`/edge.json` - An Astro API Endpoint that returns JSON data using Vercel Edge Functions
Learn more about [Astro on Vercel](https://vercel.com/docs/frameworks/astro).
Open [http://localhost:3000](http://localhost:3000) with your browser to see the result.
You can start editing the page by modifying `pages/index.js`. The page auto-updates as you edit the file.
[API routes](https://nextjs.org/docs/api-routes/introduction) can be accessed on [http://localhost:3000/api/hello](http://localhost:3000/api/hello). This endpoint can be edited in `pages/api/hello.js`.
The `pages/api` directory is mapped to `/api/*`. Files in this directory are treated as [API routes](https://nextjs.org/docs/api-routes/introduction) instead of React pages.
You can start editing the page by modifying `app/page.js`. The page auto-updates as you edit the file.
This project uses [`next/font`](https://nextjs.org/docs/basic-features/font-optimization) to automatically optimize and load Inter, a custom Google Font.
This is a [Next.js](https://nextjs.org/) with [Storybook](https://storybook.js.org/) project bootstrapped with [`create-next-app`](https://github.com/vercel/next.js/tree/canary/packages/create-next-app).
## Getting Started
First, run the development server:
```bash
npm run storybook
# or
yarn storybook
# or
pnpm storybook
```
Navigate to [localhost:6006](http://localhost:6006/).
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.
