prisma: Prisma.validator: with clientExtensions enabled, Typescript can no longer compute types

Bug description

On the most basic schema, when Client Extensions are enabled, Typescript is no longer able to properly generate types for query results. One does not need to implement any specific client extension - in fact, one doesn’t have to use them at all. Simply enabling Client Extensions completely renders any project uncompilable.

Please see the sample repository to reproduce.

How to reproduce

Please see the sample repository with full reproduction instructions here: https://github.com/jove4015/special-umbrella.

In the repo, you will see a very simple application that inserts one record into a basic table with all scalar fields and no relationships. It runs correctly without client extensions enabled, but fails the second client extensions are turned on.

Expected behavior

With client extensions enabled, Prisma should still be able to resolve types properly and compile. Client Extensions should be usable.

Prisma information

Schema:

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model TestTable {
  id          Int     @id @default(autoincrement())
  task_name   String?
  status      String?
  description String?
  notes       String?
}

Prisma version 4.9.0

Environment & setup

OS: MacOS or Debian Linux running in Docker
Database: PostgreSQL
Node.js version: v16.17.1

Prisma Version

Environment variables loaded from .env
prisma                  : 4.9.0
@prisma/client          : 4.9.0
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine ceb5c99003b99c9ee2c1d2e618e359c14aef2ea5 (at node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node)
Migration Engine        : migration-engine-cli ceb5c99003b99c9ee2c1d2e618e359c14aef2ea5 (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine    : introspection-core ceb5c99003b99c9ee2c1d2e618e359c14aef2ea5 (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary           : prisma-fmt ceb5c99003b99c9ee2c1d2e618e359c14aef2ea5 (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Format Wasm             : @prisma/prisma-fmt-wasm 4.9.0-42.ceb5c99003b99c9ee2c1d2e618e359c14aef2ea5
Default Engines Hash    : ceb5c99003b99c9ee2c1d2e618e359c14aef2ea5
Studio                  : 0.479.0

About this issue

Original URL
State: closed
Created a year ago
Reactions: 3
Comments: 16 (8 by maintainers)

Most upvoted comments

Thank you for taking the time to explain, I really do appreciate it. It took a while but I rooted out all the instances of this in our project and was finally able to get a build out of it. It’s probably for the best; it sounds like our use of the validator wasn’t having it’s intended effect anyway.

jove4015 on Feb 7, 2023

Yes, although you did define these as true, TypeScript will widen them if you don’t use our utility immediately (Also, fyi, you could as well use satisfies). So here is what you have: Screenshot from 2023-02-06 10-08-37 And here is what you’d have by using the utility immediately: As you can see, applying the utility afterwards does not preserve your initial input types. Basically our utility does domething similar as as const/statisfies for you and, similarly, it will need to be applied immediately to preserve full type information. If that wasn’t clear enough in our docs, we should improve that.

millsp on Feb 6, 2023