Drizzle Team•2mo ago

Randomly losing types for tables.

I have a mono repo setup for a bill tracking project, it's OSS so you can view it at https://github.com/sungmanito/mono -- part of the monorepo are shared drizzle definitions because I end up using them in more than one place (https://github.com/sungmanito/mono/tree/main/packages/db) Currently I've lost types for my queries. This is not the first time this has happened, but previously the culprit was that I had upgraded the drizzle-orm version in one package without updating the other(s). Each of the packages and apps are using drizzle-orm 0.44.2, confirmed in my pnpm-lockfile that there are no other listed versions. In the main web app I create a drizzle client:

import { drizzle } from 'drizzle-orm/node-postgres';
import { DB_URL } from '$env/static/private';
import Pg from 'pg';
import { exportedSchema } from '@sungmanito/db';

const client = new Pg.Pool({
  connectionString: DB_URL,
});

await client.connect();

export const db = drizzle(client, {
  logger: true,
  schema: exportedSchema,
});

import { drizzle } from 'drizzle-orm/node-postgres';
import { DB_URL } from '$env/static/private';
import Pg from 'pg';
import { exportedSchema } from '@sungmanito/db';

const client = new Pg.Pool({
  connectionString: DB_URL,
});

await client.connect();

export const db = drizzle(client, {
  logger: true,
  schema: exportedSchema,
});

and in the loader functions (sveltekit) I tend to do stuff like

import { db } from '$lib/server/db';
import { exportedSchema } from '@sungmanito/db';
export const load = async () => {
  const results = await db.select().from(exportedSchema.bills);
  return { results };
}

import { db } from '$lib/server/db';
import { exportedSchema } from '@sungmanito/db';
export const load = async () => {
  const results = await db.select().from(exportedSchema.bills);
  return { results };
}

More confusing, is if i take any of the table definitions and just include them in the repo, it works fine. The types that come back for a typical query, like where I'm loading all the bills, their most recent payment status, and the name of the household associated with that bill, is this

 ({
    [x: string]: unknown;
} | {
    [x: string]: unknown;
} | {
    [x: string]: unknown;
} | {
    [x: string]: unknown;
} | {
    [x: string]: unknown;
} | {
    [x: string]: unknown;
} | {
    [x: string]: unknown;
} | {
    [x: string]: unknown;
})[]

 ({
    [x: string]: unknown;
} | {
    [x: string]: unknown;
} | {
    [x: string]: unknown;
} | {
    [x: string]: unknown;
} | {
    [x: string]: unknown;
} | {
    [x: string]: unknown;
} | {
    [x: string]: unknown;
} | {
    [x: string]: unknown;
})[]

When it should be something more like

{ id: string; billName: string; householdName: string; householdId: string; ...}[]

{ id: string; billName: string; householdName: string; householdId: string; ...}[]

Anyone got any ideas?

GitHub

GitHub - sungmanito/mono

Contribute to sungmanito/mono development by creating an account on GitHub.

GitHub

mono/packages/db at main · sungmanito/mono

Contribute to sungmanito/mono development by creating an account on GitHub.

10 Replies

JustWayne•2mo ago

It looks like you edit your code by opening the root folder of the repo with VS Code, but you have no root tsconfig.json file in the root where VS Code would look for it. I'm not an expert in TypeScript configuration or VS Code, but what I've found is that I don't like sharing tsconfig.json between all of my packages because it's too hard to keep them all vibing together. What I used to do, was to open each package folder separately with VS Code, which simplified my life a lot because I only had to worry about one package being configured for one instance of VS Code. So in your case I would have opened apps/website in one instance of VS Code and packages/db in a different on and if I needed to work on packages/skeleton-plugin I would have opened a 3rd instance of VS Code. HOWEVER Now I just create a my-project.code-workspace file at the root of the repo and I open that file with a single instance of VS Code. In that file, I put a folders entry for each separate package. This causes VS Code to use a different runtime configuration for each of those. It's as if there are separate VS Code instances for each folder. Here's my current setup with notes:

JustWayne•2mo ago

app-cloud.code-works...

JustWayne•2mo ago

If the notes on the settings key aren't clear enough: Settings in the code-workspaces file are basically the defaults for any folder included in the code-workspaces file when VS Code is started by opening the code-workspaces file. These settings can be overridden in the separate folders by a .vscode/settings.json file. Another issue you might be running into is something that happened to me recently with TypeScript version 5.9+ : When I was investigating a TypeScript issue, I found a warning from @typescript-eslint in the VS Code output logs that said I needed to set the tsconfigRootDir in the eslint config:

languageOptions: {
  parserOptions: {
    tsconfigRootDir: import.meta.dirname, // <-- OR: __dirname I suppose
  },
},

languageOptions: {
  parserOptions: {
    tsconfigRootDir: import.meta.dirname, // <-- OR: __dirname I suppose
  },
},

So, some ideas to try: - Try opening VS Code directly to the folder of the project to see if it's different than opening the root repo. - Try adding tsconfigRootDir to eslint.config.js - If separate instances of VS Code are working better but you want to open a single instance, try creating a code-workspaces file.

jhechtfOP•2mo ago

I've had this setup for years at this point, and it's always worked; i opened up a copy that i hadn't updated on my mac; same file structure same everything else about the setup, just missing a few commits. types worked there. rebased the changes in that branch off of some of my more recent merges to main and something broke. I haven't had the chance to figure out where, but I imagine it's something with the version of drizzle more than anything because systematically nothing else has changed about the project.

jhechtfOP•2mo ago

I did do some quick-and-dirty testing and I'm noting that this happens even if i make a different package that has the schema files, but the issue "sort of" goes away if I put the client export in the database file (not something I'm keen on doing), i.e.

import { drizzle } from 'drizzle-orm/node-postgres';
import Pg from 'pg';
import * as schema from './tables';
import {
  billsRelations,
  userRelations,
  householdRelations,
  paymentRelations,
  identitiesRelations,
  invitesRelations,
  usersToHouseholdsRelations,
  objectRelations,
  bucketRelations,
} from './relations';

export const exportedSchema = {
  // Schema
  authSchema: schema.authSchema,
  // Tables
  bills: schema.bills,
  households: schema.households,
  users: schema.users,
  payments: schema.payments,
  usersToHouseholds: schema.usersToHouseholds,
  invites: schema.invites,
  objects: schema.objects,
  buckets: schema.buckets,
  // Relationships
  billsRelations,
  userRelations,
  householdRelations,
  paymentRelations,
  identitiesRelations,
  invitesRelations,
  usersToHouseholdsRelations,
  objectRelations,
  bucketRelations,
};

export default schema;

const DB_URL = process.env.DB_URL!;

const client = new Pg.Pool({
  connectionString: DB_URL,
});

await client.connect();

export const db = drizzle(client);

import { drizzle } from 'drizzle-orm/node-postgres';
import Pg from 'pg';
import * as schema from './tables';
import {
  billsRelations,
  userRelations,
  householdRelations,
  paymentRelations,
  identitiesRelations,
  invitesRelations,
  usersToHouseholdsRelations,
  objectRelations,
  bucketRelations,
} from './relations';

export const exportedSchema = {
  // Schema
  authSchema: schema.authSchema,
  // Tables
  bills: schema.bills,
  households: schema.households,
  users: schema.users,
  payments: schema.payments,
  usersToHouseholds: schema.usersToHouseholds,
  invites: schema.invites,
  objects: schema.objects,
  buckets: schema.buckets,
  // Relationships
  billsRelations,
  userRelations,
  householdRelations,
  paymentRelations,
  identitiesRelations,
  invitesRelations,
  usersToHouseholdsRelations,
  objectRelations,
  bucketRelations,
};

export default schema;

const DB_URL = process.env.DB_URL!;

const client = new Pg.Pool({
  connectionString: DB_URL,
});

await client.connect();

export const db = drizzle(client);

and then import it like so

import { exportedSchema as schema, db } from '@sungmanito/db';
const b = await db.select().from(schema.bills);

import { exportedSchema as schema, db } from '@sungmanito/db';
const b = await db.select().from(schema.bills);

b has the proper types noted. (see image)

jhechtfOP•2mo ago

and the same works for tooling calls -- if I import getTableColumns directly from drizzle-orm with this setup I still get type errors, but if i re-export it like so from db/src/index.ts like so

export const db = drizzle(client);

export { getTableColumns } from 'drizzle-orm';

export const db = drizzle(client);

export { getTableColumns } from 'drizzle-orm';

and the same seems to happen for literally all tool calls, i.e. sql, and, eq, asc etc. MK so it looks like it's my most recent commit that broke it somehow. I'm going to deep dive -- don't remember doing anything that should've messed up the types so hard but :shrug: guess we find out.

JustWayne•2mo ago

Claude Code has been pretty good at figuring out my TypeScript issues

jhechtfOP•2mo ago

after hours of digging through code, and changing nothing, it works again. I don't know. All I did was delete the node_modules and re-install some stuff like a lot (which I had done previously) and somehow that fixed it after the dozenth time.

JustWayne•2mo ago

LUL

Kevin•3w ago

@jhechtf your a life saver, i dont know why i hadn't done this yet, been pulling my hair out for a couple hours, thanks. I think upgrading to the new v2 relations api the types mustn't have been agreeing with each other

Gaming

Programming

Randomly losing types for tables.

Did you find this page helpful?