New Vercel Deployment Build Process

#1

Vercel has just released two updates to their Redwood settings and build process, which will happen automatically and transparently. Most projects should experience no change, although there might be improvements to cold start performance of Serverless functions including the graphql.js API function.

If you are deploying your Redwood project on Vercel, it would be helpful to know how (or if) these changes affect your site.

1. Default Build Command

The set of commands used to deploy on Vercel changed with Redwood v0.25. Vercel will now use a default Redwood Build Command based on your project’s Redwood version:

  • ^v0.25.0: the default command is yarn rw deploy vercel
  • otherwise, the default command is yarn rw build && yarn rw db up --no-db-client --auto-approve && yarn rw dataMigrate up

In the Vercel dashboard, you can still override the default Build Command. If you are already overriding the default with a custom command, there will be no change.

2. Serverless Functions: Build and Deployment

During the build process, Vercel is now using nft to prepare and package functions for deployments to AWS Lambdas.

  • There is no change to the architecture of the Redwood API or functions
  • The size of deployed functions will be reduced up to 60%. In our tests, the graphql.js API function was reduced from 25.5mb to 10.3mb

You will need to redeploy your site to see these changes. You can check details about your deployed functions in the “Functions” tab of your dashboard.

4 Likes
#2

I had some odd logs when I used the default commands for build, it seems like two different migration commands got run.

|17:58:49.583  |$ /vercel/workpath0/node_modules/.bin/rw deploy vercel|
|---|---|
|17:58:51.577  |$ /vercel/workpath0/node_modules/.bin/rw build|
|17:58:53.294  |Generating the Prisma client... [started]|
|17:58:56.883  |Generating the Prisma client... [completed]|
|17:58:56.895  |[22:58:56] Building "api"... [started]|
|17:59:00.479  |[22:59:00] Building "api"... [completed]|
|17:59:00.479  |[22:59:00] Building "web"... [started]|
|17:59:59.893  |[22:59:59] Building "web"... [completed]|
|18:00:00.184  |$ /vercel/workpath0/node_modules/.bin/rw prisma migrate deploy|
|18:00:01.839  |Running Prisma CLI:|
|18:00:01.839  |yarn prisma migrate deploy --preview-feature --schema "/vercel/workpath0/api/db/schema.prisma" |
|18:00:02.365  |warn @prisma/cli has been renamed to prisma.|
|18:00:02.365  |Please uninstall @prisma/cli: yarn remove @prisma/cli|
|18:00:02.365  |And install prisma: yarn add prisma|
|18:00:03.013  |Prisma schema loaded from db/schema.prisma|
|18:00:03.058  |Datasource "DS": PostgreSQL database ......|
|18:00:04.757  |11 migrations found in prisma/migrations|
|18:00:05.907  |No pending migrations to apply.|
|18:00:07.271  |$ /vercel/workpath0/node_modules/.bin/rw dataMigrate up|
|18:00:10.882  |[23:00:10] 20210201181912-20210128215616-changelog [started]|
|18:00:11.481  |[23:00:11] 20210201181912-20210128215616-changelog [completed]|
|18:00:11.487  |1 data migration(s) completed successfully.|
#3

^^ This output can be ignored. It’s effectively Prisma nudging users to switch over from @prisma/cli to a renamed prisma package. BUT the irony is that we couldn’t use that package before because it blew up the Vercel build. I’ve asked Prisma to let us turn off messages like these in the future because they don’t help most of the time and are confusing more often than not.

Otherwise, that build log looks clean and correct. Here’s what I see:

  1. rw build
  • Prisma Client generated
  • api/ and web/ built
  1. prisma migrate deploy
  • migrations applied to production DB; in this case no apply needed
  1. rw dataMigrate up
  • 1 data migration completed

Look about right and as expected?

1 Like
#4

OK, now that makes sense. So yes, that ran as expected then.

1 Like
#5

Just came across something else - I had a serverless function that did not have an async keyword but did have an await keyword inside. This caused an error in the build, but still continued and uploaded the artifacts, which in terms broke the whole site.

#6

Ah, that’s not good at all. There’s been a systemic issue with CLI commands where some exit codes were displaying correctly but effectively being swallowed. It’s fixed in v0.26.0, so :crossed_fingers:that will resolve this for you.

Keep me posted!