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
```
The `supersedes` property on the `Framework` interface may be specified by a framework in which the superseded framework should _not_ be included in the resulting framework matches during detection.
For example, a Hydrogen v2 project matches both the "remix" and "hydrogen" framework detectors, but we really only want "remix" to be selected.
When this property is set to `true`, then the corresponding `package.json` script will not be invoked, allowing for the default setting value will be executed.
This is enabled for Storybook's `buildCommand`, since we do not want the "build" script to be invoked, since that would belong to the frontend application's build instead of Storybook's.
This PR:
- updates `packages/frameworks` to have most supported frameworks specify which dependency version should reflect the overall framework version
- updates `packages/fs-detectors` to allow framework detection that returns the full `Framework` record instead of just the slug
- updates `packages/next` to return the detected Next.js version in the build result
- updates `packages/cli` to leverage these changes so that `vc build` can add `framework: { version: string; }` to `config.json` output
The result is that Build Output API and supported frameworks will return their framework version in the build result of `vc build` when possible, which is used by the build container when creating the deployment. The dashboard later retrieves this value to display in richer deployment outputs.
Supports:
- https://github.com/vercel/api/pull/15601
- https://github.com/vercel/front/pull/18319
---
With the related build container updates, we get to see Next.js version in the build output. You'll see this with BOA+Prebuilt or a normal deploy:
<img width="1228" alt="Screen Shot 2022-12-09 at 2 48 12 PM" src="https://user-images.githubusercontent.com/41545/206793639-f9cd3bdf-b822-45dd-9564-95b94994271d.png">
---
### The Path to this PR
I went through all the supported frameworks and figured out how to best determine their versions. For most of them, we can check a known dependency's installed version number.
We can get most of the way only checking npm. For a handful, we'd have to support Go/Ruby/Rust/Whatever dependencies.
I started with a more complex method signature to allow for later expansion without changing the signature. It looked like this, in practice:
```
async getVersion(dependencies: DependencyMap) => depedencies['next']
```
However, after checking all currently supported frameworks, I don't think this will end up being necessary. It also has the constraint that all dependencies have to be gathered and presented to the function even though it only needs to check for one or two. That's not a huge deal if we have them already where we need them, but we don't. We could use a variant here where this function does its own lookups, but this seemed unnecessary and would beg for duplication and small variances that could cause bugs.
Further, if we only look at `package.json`, we're going to either see a specific version of a version range. To be precise, we have to look at the installed version of the package. That means checking one of the various types of lockfiles that can exist or poking into node_modules.
If we poke into node_modules to detect the installed version, we introduce another point where Yarn 3 (default mode) will not be supported. If we read lockfiles, we have to potentially parse `npm`, `pnpm`, and `yarn` lockfiles.
If we use `npm ls <package-name>`, that also fails in Yarn 3 (default mode). We could accept that and go forward anyway, which would look like:
```
const args = `ls ${packageName} --depth=0 --json`.split(' ');
const { stdout } = await execa('npm', args, { cwd });
const regex = new RegExp(String.raw`${packageName}@([\.\d]+)`);
const matches = stdout.match(regex);
if (matches) {
return matches[1];
}
```
But it turns out there's a `--json` option! That's what I ended up using, for now.
We could explore the lockfile route more, but after some initial digging, it' non-trivial. There are 3 main lockfiles we'd want to check for (npm, pnpm, and yarn) and there are different lockfile versions that put necessary data in different places. I looked for existing tools that parse this, but I didn't find any. We could certainly go down this path, but the effort doesn't seem worth it when `npm ls` gets us really close.
---
### Follow-up Versioning
Now that we know how to determine version per framework, we can vary configuration by version. In a future PR, we could allow a given value to vary by version number:
```
name: (version) => {
if (semver.gt(version, '9.8.7')) {
return 'some-framework-2''
}
return 'some-framework';
}
```
However, it may still be easier to differentiate significant versions by adding multiple entries in the list.
This removes the reliance on raw github hosting and instead relies on the Vercel deployment hosting the logo images.
Since we already have static files in each deployment (tarballs), it makes sense to start adding static images too.
* [tests] Use `turbo` for unit tests
* .
* .
* Revert "."
This reverts commit 3d6204fef3fda3c7b4bf08955a186fe806d7c597.
* Add "src/util/constants.ts" to outputs
* .
* Add `@vercel/node-bridge` outputs
* .
* Mac and Windows
* .
* Node 14
* .
* .
* Add templates to CLI output
* Run only selected test files
* Add cross platform testing
* make test paths relative and have minimum per chunk
* add install arg
* update shell
* bump cache key
* use backslashes on windows
* pass tests as arg
* update script name
* update turbo config
* forward turbo args correctly
* dont use backslashes
* chunk integration tests instead
* update env
* separate static-build tests
* ensure unit test turbo cache is saved
* ensure turbo cache is saved for dev/cli
* fix cache key and update timeout
* Increase static-build unit test timeout
* Leverage turbo remote caching instead of actions/cache
* apply suggestions and test chunking itself
* update other ci jobs
* fix test collecting
Co-authored-by: Nathan Rajlich <n@n8.io>
This PR converts the `frameworks.json` file to TypeScript, and extends the values with the detection logic from `@vercel/static-build`, so that it's publicly editable. You also don't need to do the type casting downstream anymore.
As a consequence, it also makes Zola a 1st-class framework, as it was previously missing from the `frameworks.json` file, but present in the static-build frameworks. An example has been included based on their "Getting Started" tutorial.
CH-3808
CH-18771
This PR adds two properties to `frameworks.json`:
1. `useRuntime` - this moves the special case for non `@vercel/static-build` frontends, so that any framework can do the same as Next.js and RedwoodJS
2. `ignoreRuntimes` - this allows a framework to opt out of api detection such as RedwoodJS which handle's its own `.js` extensions
This also fixes 2 bugs discovered during implementing the feature:
1. `test-unit.yml` was not testing Node 12, it was testing 10 for both runs
2. `sortFilesBySegmentCount()` was non-deterministic causing node 10 and 12 to sort differently
This PR adds an optional property called `sort` to each framework so that we can change the order returned in the API.
The reason this is necessary is because the order of the original array determines the precedence of framework detection. So we need another way to indicate the order of templates/examples returned from the API.
In particular, we need "Next.js" to be first and "Other" to be last.
I also updated the deprecated `@now/node` usage to `@vercel/node` in the API.
We renamed the GitHub repository from `zeit/now` to `vercel/vercel` so this PR updates all references to the repo URL.
There were also a few remaining references to Now CLI that have been updated to Vercel CLI.
* Add test to frameworks
* Add example for Docusaurus v2
* Add example for ionic-angular
* Update READMEs
* Use existing versions
* Reset yarn.lock
* Add schema validation and add missing Scully.io logo
