Fix Prisma v7 paths[1] must be of type string error

A NestJS project upgraded to Prisma ORM 7 and nest start now crashes before the app logs anything useful:

[Nest] 127247  - 11/23/2025, 1:56:22 PM   ERROR [ExceptionHandler] TypeError [ERR_INVALID_ARG_TYPE]: The "paths[1]" argument must be of type string. Received undefined

TL;DR#

The crash comes from a version mismatch between the prisma CLI package and the @prisma/client package after a partial upgrade (one updated, the other left behind by a lockfile, a monorepo workspace, or a half-finished npm install). Run both packages on the exact same v7 version. Once they match, the error changes to a different, expected one: Prisma ORM v7 requires a driver adapter for every database, including PostgreSQL — install @prisma/adapter-pg and pass it to new PrismaClient({ adapter }).

Why it happens#

This was asked on Stack Overflow "Stuck with Prisma error after updating to v7" (4 votes, 5,907 views): a NestJS PrismaService that does nothing more than extends PrismaClient and calls this.$connect() in onModuleInit, failing with ERR_INVALID_ARG_TYPE the moment Nest instantiates it.

Reproducing it in a throwaway container confirms the symptom the top-voted answer describes: installing prisma@7.10.1 as the CLI but leaving @prisma/client on an older major (6.16.3 in this test) breaks prisma generate itself first:

Error:
Cannot find module '/app/node_modules/@prisma/client/runtime/query_compiler_fast_bg.postgresql.wasm-base64.js'

Running the generated client afterwards (node index.mjs, a plain new PrismaClient() with no options — the same code the Stack Overflow PrismaService calls) is what produces the paths[1] trace:

node:path:1272
      validateString(path, `paths[${i}]`);
      ^
 
TypeError [ERR_INVALID_ARG_TYPE]: The "paths[1]" argument must be of type string. Received undefined
    at Object.resolve (node:path:1272:7)
    at new t (/app/node_modules/@prisma/client/runtime/client.js:90:2154)

That Object.resolve call sits inside the generated client's runtime (runtime/client.js), not in application code. Neither the question, the answers, nor this reproduction explains exactly why path.resolve receives undefined internally — what is verified is the sequence: with the prisma CLI and @prisma/client package on different major versions (CLI 7.10.1, client 6.16.3 in this test), prisma generate itself fails with the missing-module error above, and running the app afterwards produces exactly the paths[1] trace. Reproduced on Node.js 22.23.3, PostgreSQL 16 (official Docker image), 16 October 2026: reinstalling @prisma/client@7.10.1 to match the CLI and re-running prisma generate makes the paths[1] crash disappear — the next thing new PrismaClient() throws is the driver-adapter error below, confirming the version mismatch, not the schema or the NestJS wiring, was the cause. Only the older-client case (CLI ahead of the client) was tested; a client newer than the CLI was not reproduced here.

This matches how Prisma's own v7 upgrade guide documents the release: "To upgrade to Prisma ORM v7 from an earlier version, you need to update both the prisma and @prisma/client packages" — a partial upgrade, common when a monorepo has the CLI as a dev dependency in one workspace and the client as a runtime dependency in another, is exactly the state that triggers this crash.

The same guide also raises the minimum runtime: Node.js 20.19.0, with 22.x recommended, and TypeScript 5.4.0 minimum, 5.9.x recommended. An old Node.js binary is not what caused this particular crash in the reproduction above — the error still appeared on a current Node.js 22.23.3 once the versions were split on purpose — but it rules out one more variable before assuming the versions are the only thing to check: if node --version is below 20.19, upgrade that first, separately, and re-test.

Fix#

1. Check what is actually installed. A mismatch is easy to miss in a lockfile, especially in a workspace where a shared dependency can resolve to two different places.

   bash

   npm ls prisma @prisma/client

   A split install shows two different major versions here — for example prisma@7.10.1 next to @prisma/client@6.16.3 — exactly the pairing that produced the paths[1] crash in the reproduction above. If both lines already show the same major version, a cross-major split is ruled out; the reproduction only tested that case, so still align the two packages on the exact same version before looking elsewhere.

2. Install the same v7 major version for both packages:

   bash

   npm install @prisma/client@7
   npm install -D prisma@7

   On pnpm or yarn, the official guide gives the equivalent commands; the fix is the same — both packages on the identical major.

3. Regenerate the client so its runtime matches the reinstalled package:

   bash

   npx prisma generate

4. Confirm the versions agree:

   bash

   npx prisma --version

   The prisma and @prisma/client lines must show the same version.

Verify the fix#

Run the app again (nest start, or any script that instantiates PrismaService). The ERR_INVALID_ARG_TYPE: The "paths[1]" argument trace is gone — in the reproduction above, the same node index.mjs command that previously crashed on path.resolve no longer throws that TypeError at all. Instead, it throws a different, named error:

PrismaClientInitializationError: PrismaClient was instantiated without any options. A driver adapter is required to connect to your database.

The next error: "a driver adapter is required"#

This is not a second bug — it is Prisma ORM v7 doing what its upgrade guide says it now does for every database: "The way to create a new Prisma Client has changed to require a driver adapter for all databases. […] if you are using Prisma Postgres, you now need the @prisma/adapter-pg adapter." A bare new PrismaClient() — the exact code in the question's PrismaService — no longer connects to anything on its own.

Install the adapter and the pg driver it wraps:

npm install @prisma/adapter-pg pg

Then pass the adapter to the constructor instead of relying on the schema's datasource block alone:

import { Injectable, OnModuleInit, OnModuleDestroy } from '@nestjs/common';
import { PrismaClient } from '@prisma/client';
import { PrismaPg } from '@prisma/adapter-pg';
 
@Injectable()
export class PrismaService extends PrismaClient implements OnModuleInit, OnModuleDestroy {
  constructor() {
    const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL });
    super({ adapter });
  }
 
  async onModuleInit() {
    await this.$connect();
  }
 
  async onModuleDestroy() {
    await this.$disconnect();
  }
}

Reproduced against a postgres:16 container with the equivalent plain script: $connect() resolves and the process logs connected ok, with no paths[1] and no PrismaClientInitializationError.

Pass connectionString, not url, to PrismaPg — one answer on the same Stack Overflow thread reports the adapter failing to extract the password when configured with url instead. This article's own reproduction only exercised connectionString, which worked; it does not confirm the url failure, so treat that specific claim as reported, not verified here.

One more thing the upgrade guide flags for this exact change: "Driver adapters use the connection pool settings from the underlying Node.js database driver, which may differ significantly from Prisma ORM v6 defaults. […] the pg driver has no connection timeout by default (0), while Prisma ORM v6 used a 5-second timeout." If requests under load start hanging instead of failing fast after this migration, that default — not a regression in the adapter — is usually why.

If a PrismaService in NestJS then fails to compile on a raw query with TS2345, see Prisma $queryRaw TS2345: 'string' not assignable to Sql: a call-syntax error (a template literal wrapped in brackets), unrelated to the version split.

Readers still on Prisma ORM 6 or earlier whose app fails at runtime with "Query Engine Library Not Found" have a different problem: a native query engine built for another OS or OpenSSL version, covered in Fix Prisma Query Engine Library Not Found. It does not apply to the v7 crash above, where the missing file is part of the client runtime.

If connectionString arrives empty, remember that the Prisma ORM 7 upgrade guide states that "environment variables are not loaded by default": load them explicitly, for example with import "dotenv/config" at the top of prisma.config.ts. The v6-era version of the same symptom, an env("DATABASE_URL") lookup in schema.prisma that fails, is covered in Prisma: Environment variable not found: DATABASE_URL.

A version mismatch between a CLI and its client package is not unique to Prisma, but the symptom — a generic Node.js TypeError with no mention of versions — is what makes it hard to diagnose from the stack trace alone. Checking npm ls for the two packages is the fastest way to confirm or rule it out before looking anywhere else in the schema or the NestJS module.