What Happens When You Regenerate Your Types

When you change your database and regenerate your Supabase types, you're telling the entire codebase:

The blueprint has changed. Something was added or removed. Check all the code against this new blueprint.

Three things can happen:

1. Code has a property the blueprint doesn't — red squiggle. You're passing something TypeScript has no record of.
2. Code is missing a property the blueprint has — usually a red squiggle, unless that property is marked optional.
3. A type in the code doesn't match the type in the blueprint — always a red squiggle. No exceptions.

That workflow you've been doing in Supabase — push migration, regenerate types, chase the squiggles — that's TypeScript doing exactly what it was built to do. Surfacing every place in your codebase that needs to catch up, before anything breaks in production.

Optional properties

Not every property on an object always exists. A user might not have a profile picture yet. A pet might not have a vet assigned. TypeScript handles this with the ? symbol:

interface Pet {
  name: string
  species: string
  age?: number      // optional — might not be there
  vetName?: string  // optional — might not be there
}

The ? tells TypeScript: this property doesn't have to be present. But if it is there, it still has to be the right type.

When you flip a column from nullable to required in your database and regenerate types, the ? disappears from the interface. TypeScript then immediately shows you every place in your code that was treating that field as optional — because it isn't anymore.

You've already done this. Now you know what was happening at every step.