Fixing Prisma Import Errors in a TypeScript GraphQL Setup

I recently ran into a frustrating issue while integrating Prisma with a TypeScript and GraphQL project. Everything seemed fine—my schema was written, the database was connected, and the server code was in place. But when I tried to start the server, I was hit with a cryptic error:

Error: ERR_UNSUPPORTED_DIR_IMPORT ...src/generated/prisma

Initially, I wasn’t sure what was going wrong. The error message pointed to the Prisma client import. I had assumed importing the folder like this would work:

import { PrismaClient } from './src/generated/prisma';

Unfortunately, that’s not how ES modules work in Node.js—especially with TypeScript and the --loader ts-node/esm flag. Node.js doesn't support importing directories as modules unless there's an index.js file, and Prisma doesn't generate one by default.

How I Tracked Down the Issue

After reading through the stack trace and double-checking my paths, I noticed the actual Prisma client lived inside the generated folder but wasn’t exposed directly via the directory. The fix came down to adjusting the import to point to the actual client entry file.

Instead of:

import { PrismaClient } from './src/generated/prisma';

I updated it to:

import { PrismaClient } from './src/generated/prisma/index.js';

Boom! That did the trick. The server started up without a hitch, and the error was gone. The issue wasn’t with Prisma itself, but rather how Node.js handles module resolution in ESM mode.

Why This Happens

If you're using ESM in Node.js and TypeScript together, the module resolution rules are a bit stricter. Node.js doesn’t automatically resolve directory imports to an index.js file unless it's explicitly defined or bundled.

Since Prisma generates an index.js file under its output folder, you just need to make sure your import points directly to it. And don’t forget the .js extension in the import path—this is required in native ESM mode.

Steps to Avoid This in Future Projects

1. Always specify the full path including the file name when importing Prisma client in ESM.

2. Use the latest version of Prisma to ensure compatibility with ESM setups.

3. Generate the Prisma client after making schema changes using npx prisma generate.

4. Consider aliasing imports with tools like tsconfig paths for cleaner code (though keep in mind these don’t help Node's ESM resolution).

Bonus: Prisma Generate Reminder

Another common gotcha is forgetting to generate the Prisma client after modifying your schema. If you see an error like this:

@prisma/client did not initialize yet. Please run "prisma generate"

Just run:

npx prisma generate

This regenerates the client code in the configured output directory. Without it, Prisma can’t initialize the database layer, even if your schema is valid.

Final Thoughts

This small change saved me a lot of time and confusion. Sometimes, what looks like a complex bug is just a matter of understanding how the module system works—especially in the context of newer tools and TypeScript integrations.

If you're working with Prisma, GraphQL, and Node.js using TypeScript and ESM, double-check your import paths and make sure they end with the correct file extension. It’s a small detail, but it can save you hours of debugging.

I'll continue documenting more lessons I encounter in this series as I build a complete GraphQL API with robust tooling and production-ready structure.