Live Typescript and Dramatic intellisense slowdown across import boundary

[airtonix]

https://colinhacks.com/essays/live-types-typescript-monorepo (option 5)

Recently my typescript monorepo constructed in the manner of

• recommend by this page https://moonrepo.dev/docs/guides/javascript/typescript-project-refs
• using packemon
• also using tsconfig.paths and tsconfig.references

It ran into an issue of typescript just failing to return intellesense data in a timely manner (read: immediately)

my setup is rougly like:

apps/
  app-one/
    routes/
      user/
        user.routes.ts
        user.errors.ts
      api.routes.ts
    hono-app.ts

pkgs/
  service-db/
    schemas/
      user.table.ts
    resources/
      user.service.ts
    schema.ts
    resource.ts
    index.ts

inside user.table.ts I had my drizzle table and i was using drizzle-zod to generate insert/update/select zod schemas (I also migrated to arktype but that didn't solve my issue).

Trying to import the user zod schemas into my user.routes.ts resulted in having to wait (in most cases), 2-3minutes for intellisense information to appear in the mouse over tooltip (outrageous).

import { insertUserSchema } from '@workspace/service-db/schema'; 
import type { InsertUser } from '@workspace/service-db/schema';

export userRoutes = new Hono<AppContext>()
  .post('/',
    zodValidator('json', insertUserSchema),
    (c, next) => {
      const payload = c.req.valid('json');
      // something something something do db things.
    })

userRoutes ends up being used to create client side types for hono rpc browser client, so the zodValidator/arktypeValidator is pretty important.

Things I noticed:

• if manually create the zod/arktype schema here in the user.routes.ts file, intellisense is near-instant.
• if i remove zodValidator/arktypeValidator and don't have request validation, i obviously don't have the issue.
• I tried removing all references from tsconfig and instead put @workspace/service-db in the app-one/package.json, this now requires a moon service-db:build every time i make a change in service-db (not really what i want to be doing). and in the end, my intellisense problem is still there. (I had thought that direct source file inference was the cause of slowdown.
• If i stop using drizzle-zod or drizzle-arktype to generate validation schemas from the drizzle table classes, and instead just manually create schemas, then this still does not fix the slow down (only if i create these schemas in the same file as the user.routes.ts)
• If I use drizzle-zod or drizzle-arktype to generate the schemas in the user.routes.ts and only import the UserTable class from @workspace/service-db, again... does not solve the problem.

Note

It feels like the problem has some kind of relation to the import boundary?

---

The point

https://colinhacks.com/essays/live-types-typescript-monorepo (option 5)

Would this speed things up?

what could be causing this dramatic slow down?

[milesj]

Have you ran tsc with diagnostics on to figure out what's causing the slowdown?

Also, are you relying on a build step first to generate the types?

[airtonix]

Have you ran tsc with diagnostics on to figure out what's causing the slowdown?

Not yet. 😅

"extendedDiagnostics": true

Put this on all pkgs/apps or just the app or just the service-db pkg?

Also, are you relying on a build step first to generate the types?

I wasn't initially as i built this repo out, but as one of the attempts to 50/50 remove the slowdown, i moved to relying on types creates from a build step.

[airtonix]

Running the diagnostics revealed stuff I wasn't sure about yet, some non obvious data apart from the fact that typescript was using 4gb of memory, but i supposed that's normal in the whole schema of everyone-thinks-javascript-sniffs-glue story

For the time being, to avoid an apocalypse of Bike Sheds, I downgraded typescript from 5.9.2 to 5.8.3.

and the problem... went away.

I hope this isn't the equivalent of turning errors off. 😅

😓

[milesj]

Interesting that downgrading worked. It sounds like a TS regression, I would check their issues for anything relevant.

As for diagnostics, you can also pass --extendedDiagnostics to tsc.