Adding Your Framework

You can add support for a new framework on Vercel by adding its default requirements to the @vercel/frameworks package and the @vercel/static-build package:

1. Create a Pull Request on the Vercel repository and add your framework to the @vercel/frameworks package. The required file is located in ./packages/frameworks/frameworks.json. You can copy the structure of an existing one and adjust the required fields. Note that the settings property either contains a value or a placeholder. The value property is used when something is not configurable, the placeholder is used when something is configurable and can be changed with configuration. An example would be the Output Directory for Hugo, it's public by default but can be changed through its config file, so we use placeholder with an explanation of what can be used.
2. Add an example to the ./examples directory: The name of the directory should equal the slug of the framework used in @vercel/frameworks. The .github/EXAMPLE_README_TEMPLATE.md file can be used to create a README.md file for the example.
3. Update the @vercel/static-build package: The file ./packages/now-static-build/src/frameworks.ts has to be extended. You can add default routes that will always be applied to projects that use this framework or specify some paths that will be cached to speed up the build process. Note that this step can be ignored if the framework makes use of the file system API.
4. After your Pull Request has been merged and released, other users can select the example on the Vercel dashboard and deploy it.

File System API

A more sophisticated way to ensure a framework works on Vercel, would be to let the framework use the file system API. This allows the framework to place its build outputs inside of specific directories during the build step. The files will then be used depending on which directory they have been put in.

The following use cases can be used with their respective directories:

Static Files

Files placed in .vercel_build_output/static will be served as static files. All other output directories for static files will be ignored if this directory is present and has files.

Serverless Functions

Files that match the path .vercel_build_output/functions/<language>/<name>/index.<extension> will become serverless functions. The language part is the programming language used for the function, the extension part would be the file extension for that language. At the moment only node is supported as language and js as extension. The name is the name of the function under which it'll be available.

The index file inside of the name directory will be the entrypoint of the function. All other files in that directory and subdirectories will be bundled with the serverless function, so they'll be available at runtime. As a result, it's not possible to have a name that's more than one path segment, meaning my-function is valid, but my/function would not.

The serverless functions will be accessible at /.vercel/functions/<name> on the deployment. Routes can then be used to create rewrites for those functions.

Routes

The file .vercel_build_output/config/routes.json can be used to create Routes for the deployment.

A common use case could be to have a catch all route that is a rewrite to a serverless function combined with some static assets. The routes.json file might then look like this:

[
  { "handle": "filesystem" },
  {
    "src": "/(.*)",
    "dest": "/.vercel/functions/renderer"
  }
]

The "handle": "filesystem" part is required in this case, as the catch all route would otherwise rewrite all requests to the static assets to the renderer function.