How I Resolved Prisma Issues and Fixed Vercel 500 INTERNAL_SERVER_ERROR 🚀

Kamil Owczarek — Mon, 27 May 2024 18:29:52 +0000

Yesterday, I moved an old application from my own hosting to Vercel. Although I anticipated some challenges, I encountered an issue that took longer to resolve than expected. Here’s how I navigated the problem and found a solution, so you can save time if you face the same problem! 😊

Step 1: Update Prisma and @prisma/client

First, make sure you are using the latest versions of Prisma and @prisma/client. For my project, the latest version at the time was 5.14.0. Run the following command to update them:

npm install prisma@5.14.0 @prisma/client@5.14.0 --save-dev

Step 2: Initial Setup

After deploying to Vercel, I noticed the following error in Vercel's logs:

Prisma has detected that this project was built on Vercel, which caches dependencies.
This leads to an outdated Prisma Client because Prisma's auto-generation isn't triggered.
To fix this, make sure to run the `prisma generate` command during the build process.

Learn how: https://pris.ly/d/vercel-build

Step 3: Following the Instructions

The error message was clear. To fix it, I needed to add the following to my package.json:

"postinstall": "prisma generate"

Step 4: Adding a Build Command

However, this didn't completely resolve the issue. So, I updated Vercel's build command to ensure Prisma generates the client before building the application:

"build": "npx prisma generate && next build"

Step 5: Encountering a New Issue

After this change, my application built successfully, but all API calls returned a Vercel 500: INTERNAL_SERVER_ERROR. This was frustrating, and there wasn’t much information available on how to fix it. 😤

Step 6: Debugging the Problem

After a few hours of trial and error, I found the problem in my schema.prisma file. Here’s what my initial setup looked like:

generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "linux-musl"] // <- Required on Ubuntu
}

datasource db {
  provider     = "postgresql"
  url          = env("DATABASE_URL")
  relationMode = "prisma"
}

This setup worked fine on my server but caused issues on Vercel as I forgot it was customed specificlly for Ubuntu.

Step 7: Correcting the Schema

Here are the correct settings:

generator client {
  provider      = "prisma-client-js"
  previewFeatures = ["driverAdapters"] // <- neon.tech
}

datasource db {
  provider     = "postgresql"
  url          = env("DATABASE_URL")
}

Step 8: Sleep

With these adjustments, my application ran smoothly on Vercel. Finally, I could get some well-deserved rest! 🎉

I hope this will save someone time! ⏳

Source

The Power of Typescript Satisfied Operator in Less than 2 Minutes

Kamil Owczarek — Mon, 27 May 2024 10:34:20 +0000

By default, TypeScript tries to recognize the type of a variable by itself, meaning there is always some kind of type, no matter what we do.

const user = {
    id: 1,
    email: 'example@mail.com',
};

typeof user = {
    id: number // generated automatically
    email: string // generated automatically
};

Already existing keys can only be changed to a value that matches the previously declared type. In this case, email was a string, so we can only change it to a string.

This also means the object will always maintain the same, expected shape.

const user = {
    id: 1, // Read as number
    email: 'test@mail.com', // Read as string
};

user.email = "example@email.com";
user.email = true; // ERROR: Type 'boolean' is not assignable to type 'string'
user.notExisting = 'Test'; // ERROR: Property 'notExisting' does not exist on type '{ id: number; email: string; }'

In real projects, relying only on TypeScript's assumption of types might not always work as we might find ourselves in situations where we don't want to allow all types.

For this reason, we can use variable annotation.

// variable annotation
const user: Record<string, string | number | boolean> = {
    id: 1,
    email: 'test@mail.com',
};

This method works on the variable level, which means we change the way TypeScript sees the type of the variable. It no longer tries to recognize it by itself.

In this case, it doesn't know we have an email key, it only knows there should be a string as a key and the value is a string, number, or boolean.

const user: Record<string, string | number | boolean> = {
    id: 1,
    email: 'test@mail.com',
};

user.email = 'example@.com';
user.email = true;
user.notCorrectValue = {}; // ERROR: Type '{}' is not assignable to type 'string | number | boolean'

console.log(user.neverExisting); // <- We can read a value that never exists

It works, but without TypeScript's assumption, we are able to create keys that never existed as well as read keys, which we shouldn't read as long as we follow the type.

It's a behavior that has very rare use cases as it ruins the whole idea behind type-safe writing of code.

We should tend to keep TypeScript's assumption working, but we couldn't really do anything about it... until we got the satisfies operator.

The satisfies operator, compared to previous methods, works on values, not variables, which means it checks if the current type matches (satisfies) the selected type, leaving type assumption to TypeScript.

const user = {
    id: 1,
    email: 'asdsadas',
} satisfies Record<string, string | number | boolean>;

user.id = "string Id"; // ERROR: Type 'string' is not assignable to type 'number'
user.email = 'example@.com';
user.test = true; // ERROR: Property 'test' does not exist on type '{ id: number; email: string; }'
user.email = true; // ERROR: Type 'boolean' is not assignable to type 'string'

It allows TypeScript to assume that the declared object has the expected type and contains only id as number and email as a string.

The satisfies operator provides a check without having any impact on the type.

type User = Record<string, string | number | boolean>;

const USER_: User = {
    email: '1',
} as const;

USER_.email; // <- `email` is shown as `string | number | boolean`

const USER = {
    email: '1',
} as const satisfies User;

USER.email; // <- `email` is shown as `1`

Yet the true power of satisfies comes in connection with as const, where the lack of overwriting types allows TypeScript to show the developer exact values.

So remember my dear dev, satisfies checks the type of an object, without having impact on the TypeScript's assumption and should be one of your main ally again typing constant objects.