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.
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.
2023-01-13 22:24:31 +00:00
957 changed files with 132804 additions and 42240 deletions
`@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.
@@ -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`
4. Add `target: 'serverless'` to `next.config.js` [deprecated]
```js
module.exports={
@@ -33,13 +35,15 @@ module.exports = {
};
```
4. Remove `distDir` from `next.config.js` as `@now/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`
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.
This directory is a brief example of a [Gatsby](https://www.gatsbyjs.org/) app that can be deployed to Vercel with zero configuration.
> **Note:** We do not currently support some Gatsby v5 features, including API Routes and DSG. We are actively working on adding support for these features.
> **Note:** SSR, DSG, and API Routes [are now supported](https://vercel.com/changelog/improved-support-for-gatsby-sites). We do not currently support some Gatsby v5 features, including Partial Hydration and the Slice API.
This directory is a brief example of a Vite/Vue.js site that can be deployed to Vercel with zero configuration.
This template should help get you started developing with Vue 3 in Vite. The template uses Vue 3 `<script setup>` SFCs, check out the [script setup docs](https://v3.vuejs.org/api/sfc-script-setup.html#sfc-script-setup) to learn more.
While this project uses Vue.js, Vite supports many popular JS frameworks. [See all the supported frameworks](https://vitejs.dev/guide/#scaffolding-your-first-vite-project).
@@ -12,18 +12,10 @@ Deploy your own Vite project with Vercel.
To get started with Vue.js deployed with Vercel, you can use Vite (https://vitejs.dev/guide/#scaffolding-your-first-vite-project) to initialize the project:
```shell
$ yarn create @vitejs/app
```
### Deploying From Your Terminal
You can deploy your new Vite project with a single command from your terminal using [Vercel CLI](https://vercel.com/download):
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.
