The previous logic was checking for the env var `ENABLE_EXPERIMENTAL_COREPACK` to determine if corepack was being used by a project. However, this value only means that the build system should consider corepack, not that it's actively being used.
We need to check that flag AND the existence of a `packageManager` property in the project's `package.json`.
My project was being incorrectly detected as not vite, thus it was failing in runtime. My vite config is `vite.config.mts` so this PR fixes detection logic to include `mjs` and `mts` extensions.
The fix can be generalized if needed.
In legacy Remix apps, we were running `npm install` once again before globbing the `node_modules` dir due to the injecting of the forked Remix compiler which would cause a cache miss without that happening.
For Vite, we are no longer mucking about `node_modules` at build-time, so there is no need to run `npm install` in the `prepareCache()` function.
There is also no "cacheDirectory" setting so the globbing of the legacy cache directory is also moved into the legacy-only logic.
**tl;dr** For Remix + Vite apps, the only thing that needs to be cached is `node_modules`.
In particular, when both `remix.config` and `vite.config` files exist,
run some additional checks to try to detect if the project is using the
Vite plugin or not.
This function can lead to unexpected results (for example, in a monorepo setup where there were different versions of Remix being used, I encountered the wrong version of Remix being symlinked causing issues at runtime).
Instead, throw an error at build time at the NFT step if `@remix-run/node` is missing for routes using Node.js, or when `@remix-run/server-runtime` is missing for routes using Edge.
Less magical is better. Explicit is better than implicit.
Customer reported an edge case where (in a monorepo) their project's
`package.json` did not list any dependencies (instead they are listed at
the root-level `package.json`) and this caused the `node_modules`
directory to not exist in the app subdirectory, causing
`ensureSymlink()` to fail.
Adds support for Remix apps which use the new Remix Vite plugin.
* The vanilla Remix + Vite template deploys correctly out-of-the-box,
however only a single Node.js function will be used, and a warning will
be printed saying to configure the `vercelPreset()` Preset.
* When used in conjunction with the `vercelPreset()` Preset
(https://github.com/vercel/remix/pull/81), allows for the application to
utilize Vercel-specific features, like per-route `export const config`
configuration, including multi-runtime (Node.js / Edge runtimes) within
the same app.
## To test this today
1. Generate a Remix + Vite project from the template:
```
npx create-remix@latest --template remix-run/remix/templates/vite
```
1. Install `@vercel/remix`:
```
npm i --save-dev @vercel/remix
```
1. **(Before Remix v2.8.0 is released)** - Update the `@remix-run/dev`
dependency to use the "pre" tag which contains [a bug
fix](https://github.com/remix-run/remix/pull/8864):
```
npm i --save--dev @remix-run/dev@pre @remix-run/serve@pre
```
1. Configure the `vercelPreset()` in the `vite.config.ts` file:
```diff
--- a/vite.config.ts
+++ b/vite.config.ts
@@ -1,10 +1,11 @@
import { vitePlugin as remix } from "@remix-run/dev";
import { installGlobals } from "@remix-run/node";
import { defineConfig } from "vite";
+import { vercelPreset } from "@vercel/remix/vite";
import tsconfigPaths from "vite-tsconfig-paths";
installGlobals();
export default defineConfig({
- plugins: [remix(), tsconfigPaths()],
+ plugins: [remix({ presets: [vercelPreset()] }), tsconfigPaths()],
});
```
1. Create a new Vercel Project in the dashboard, and ensure the Vercel
preset is set to "Remix" in the Project Settings. The autodetection will
work correctly once this PR is merged, but for now it gets incorrectly
detected as "Vite" preset.
* **Hint**: You can create a new empty Project by running the `vercel
link` command.
<img width="545" alt="Screenshot 2024-02-27 at 10 37 11"
src="https://github.com/vercel/vercel/assets/71256/f46baf57-5d97-4bde-9529-c9165632cb30">
1. Deploy to Vercel, setting the `VERCEL_CLI_VERSION` environment
variable to use the changes in this PR:
```
vercel deploy -b
VERCEL_CLI_VERSION=https://vercel-git-tootallnate-zero-1217-research-remix-v-next-vite.vercel.sh/tarballs/vercel.tgz
```
Adds a check to ensure the `serverBuildPath` for the server bundles was created. If it was not, then that means the Vercel forked Remix compiler was not used, and we must fall back to a singular server bundle.
The fork of the Remix compiler is only necessary when the project is utilizing split configurations in their routes (i.e. mixing Node.js and Edge functions).
However, the injecting of the forked compiler has proven to be brittle and has many edge cases which cause the fork to not be present. Considering that the more common case is to _not_ use split configuration, skip the fork entirely when that is the case.
This is somewhat of a band-aid / hold over for the "old" Remix. With the Remix + Vite configuration, the fork will be entirely unnecessary.
Fixes an edge case where a route without a path was causing the build to
fail. Reproducible with this `remix.config.js` file:
```js
export default {
ignoredRouteFiles: ["**/.*"],
routes(defineRoutes) {
return defineRoutes((route) => {
route("/", "foo.tsx", { index: true });
});
},
};
```
The `name` property of the `EdgeFunction` class is no longer necessary
on the infra side. Instead, its value is inferred based on the URL path
that the function is representing. So deprecate the property on the
class, and remove its usage throughout the codebase.
https://github.com/vercel/vercel/pull/10819 introduced a bug causing the `prepareCache()` function to fail (due to `@remix-run/dev` no longer being require-able). Even if it were not failing, the deps installed are not a valid representation of the user's `package.json` / lockfile. So to have more truthful cache contents, run `npm install` once again during `prepareCache()` to fix both issues at the same time.
User reported a scenario in which npm was ignoring the second `npm install` command to replace the Remix compiler with our forked version. This seems like a bug in npm. Workaround that seems to work is to remove `@remix-run/dev` entirely and install our forked version as a "standard" dependency (instead of using the `npm:` syntax). The `bin` entry for `remix` should at that point be our forked compiler.
In order to make the default mock shop created from `npm create @shopify/hydrogen@latest` work out-of-the-box and without additional configuration, set the necessary default environment variables to make the server not render an error.
Enables support for Hydrogen v2 apps using the "Remix" preset. This initial support works with the Hydrogen demo store template unmodified, and all pages will use Edge functions.
Node.js runtime, and also any other configuration via `export const config`, are not supported at this time, due to some pending blockers.
The Remix application might _also_ be the root of a workspace, so check for that case and pass the appropriate flag to the package manager to make it not error.
See: https://github.com/orgs/vercel/discussions/3467
Instead of including the fork `@remix-run/dev` package as a regular dependency of `@vercel/remix-builder`, install it at build-time by modifying the project's `package.json` file. The reasons for this are:
* Avoids deprecation warnings from a few packages that currently exist on the `@remix-run/dev` package when installing Vercel CLI (those warnings already show up in the build logs anyways, so nothing new there).
* Allows us to install a version as close as possible to the version specified in the user's `package.json` (similar to how we do when auto-injecting the `@vercel/remix` package). This will be especially important once Remix v2 is released, which will have breaking changes compared to v1.
**Note:** `@vercel/remix-run-dev` is still a _dev_ dependency, so that we can use TypeScript types from it, as well as, at runtime, we use the version in the Builder's `package.json` to determine the maximum versions of `@vercel/remix-run-dev` and/or `@vercel/remix` which can safely be installed.
Fixes#10027.
Fixes#10222.
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.
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.
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.
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.
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.
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.
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.
