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.
^^ 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:
rw build
Prisma Client generated
api/ and web/ built
prisma migrate deploy
migrations applied to production DB; in this case no apply needed
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.
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 that will resolve this for you.