$extends TS error: "Inferred type of this node exceeds the maximum length the compiler will serialize" with "declaration": true in tsconfig

[mshd]

The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.

This error also showed up in another project.

Source file. To reproduce, check out main, and upgrade to Prisma 4.7

[eviefp]

Can you confirm this is a regression from 4.6.x, as in, it used to work and it's no longer working?

[mshd]

Can you confirm this is a regression from 4.6.x, as in, it used to work and it's no longer working?

Um no, I'm just trying this feature for the first time as it was just released in version 4.7.0

[yovanoc]

I confirm a regression, I have this too on just a new PrismaClient()

[miguelff]

Hey, @mshd we need the schema to be able to reproduce the problem. So far, I have been able to successfully generate the client using the following schema:

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["clientExtensions"]
}

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

model Image {
  id       Int     @id @default(autoincrement())
  imageUrl String? @unique
}

And to extend it to compute the image URL from the id:

import { PrismaClient } from '@prisma/client'
export const prismaClient = new PrismaClient().$extends({
    result: {
        image: {
            imageUrl: {
                needs: { id: true },
                compute: ({ id }) => {
                    return `https://storage.googleapis.com/entitree-images/${id}.jpg`;
                },
            }
        }
    }
})

async function main() {
    await prismaClient.image.create({ data: {} })
    const image = await prismaClient.image.findFirst()
    console.log(image?.imageUrl)
}

main()
    .then(async () => {
        await prismaClient.$disconnect()
    })
    .catch(async (e) => {
        console.error(e)
        await prismaClient.$disconnect()
        process.exit(1)
    })

Here's a zip ball with the reproduction: repro.zip

[miguelff]

I also tried using This schema, and both generation and execution against postgres worked correctly too.

[aqrln]

Hi @mshd and thank you for your report! This error is related to failure to emit declarations — notice that despite the error, if you hover the mouse over the variable in your editor, you can still see that TypeScript infers a type. Adding

"compilerOptions": {
  "declaration": false
}

to tsconfig.json prevents the issue, so this is the workaround for now. We will work on investigating and fixing the root cause, as of course the functionality should work regardless of this compiler option. Thanks for bringing this to our attention.

[aqrln]

@yovanoc I can't reproduce this with just new PrismaClient() without $extends even under the conditions where this happens for the OP. Could you please open a new issue with details and reproduction? Thank you!

[yovanoc]

@aqrln Ok can't reproduce after deleting node_modules and cleaning the project. But found another interesting error

#16545

[millsp]

Hey @mshd I am not able to reproduce this exact same error. However, after taking a look at the generated types, I found that there is a clash with our Metric type (which is part of the metrics preview feature). What I am seeing is a broken index.d.ts file, but I cannot get the error you're showing. Could you:

1. Try to comment out any Metric related models/enums in your schema and re-generate to see if the error persists
2. If the error persists, could you give us instructions to reproduce this on your repository? Thanks

[mshd]

@millsp I think it's only related to declaration: true.
@aqrln Thanks so much, this solved it for now.
@miguelff By using your repro.zip and adding declaration: true in tsconfig.json, you can reproduce the error.

[adamhamlin]

Any movement here? Or a workaround other than declaration: false? (we're using a composite project, so I think a non-starter for us).

Currently seeing this against 4.16.x. For reference, using a single extension specifying $allModels (and we have ~90 models, so it makes sense it would be a lengthy type):

[janpio]

Any additional information you can give us @adamhamlin to reproduce and understand what is going on? We thought this was fixed in December :/

[adamhamlin]

Any additional information you can give us @adamhamlin to reproduce and understand what is going on? We thought this was fixed in December :/

@janpio I kind of alluded to it, but my suspicion is that the use of $allModels + a non-trivial number of models sort of explodes the type size. But I'll try to post a minimal reproducible example

[millsp]

@adamhamlin You are correct, or at least from my first investigation performance issues are arising with how we deal with intersections, which are inefficient, on $allModels. Currently, I consider your issue to be 100% related to what's been reported at #19999, for some it will be a length serialization error, for others it will be memory exhaustion (I've seen both while investigating the issue).

[millsp]

At the moment, my minimal reproduction is the following. Could you confirm this also fails on your end?

const prisma = new PrismaClient().$extends({
    model: {
        $allModels: {
            async paginate<T, A>(
                this: T, args: Prisma.Exact<A, Prisma.Args<T, "findMany">>
            ) {
                return {} as Prisma.Result<T, A, "findMany">
            }
        }
    }
})

[adamhamlin]

At the moment, my minimal reproduction is the following. Could you confirm this also fails on your end?

@millsp yes, confirming the same issue using your example

[millsp]

Hey @adamhamlin, we have a branch/fix for you to try over here. If you have some time, I'd love if you could give it a try and let me know if that helped. Thanks.

[adamhamlin]

Hey @adamhamlin, we have a branch/fix for you to try over here. If you have some time, I'd love if you could give it a try and let me know if that helped. Thanks.

@millsp interestingly the new branch resolved the issue when using your minimal/toy example, but it did not when using my actual extension. I'll just go ahead and post my extension here in case that helps (it's more or less copied/adapted from this). Also, no change if using Prisma.defineExtension or putting the object directly into $extends(...).

const createManyAndReturnWithIdsExtension = Prisma.defineExtension((client) => {
    return client.$extends({
        name: 'createManyAndReturnWithIds',
        model: {
            $allModels: {
                /**
                 * Bulk insert the specified inputs and return with ID information
                 */
                async createManyAndReturnWithIds<T, A>(
                    this: T,
                    args: Prisma.Exact<A, Omit<Prisma.Args<T, 'createMany'>, 'skipDuplicates'>>,
                ): Promise<Array<Prisma.Result<T, A, 'create'> & { id: number }>> {
                    const thisCast = this as any;
                    const argsCast = args as any;

                    argsCast.data.forEach((record) => {
                        if (record.id) {
                            throw new Error('Cannot provide explicit IDs when using createManyAndReturnWithIds');
                        }
                    });

                    const ctx = Prisma.getExtensionContext(this);
                    const tableName = _.kebabCase(ctx.name);
                    const numRecords = argsCast.data.length;

                    const ids = (
                        await client.$queryRaw<Array<{ id: bigint }>>`
                            SELECT nextval(pg_get_serial_sequence(${tableName}, 'id')) AS id
                            FROM generate_series(1, ${numRecords})
                        `
                    ).map((row) => Number(row.id));

                    const newRecords = argsCast.data.map((record, idx) => {
                        return {
                            id: ids[idx],
                            ...record,
                        };
                    });

                    await thisCast.createMany({
                        ...argsCast,
                        data: newRecords,
                    });

                    return newRecords;
                },
            },
        },
    });
});

[millsp]

Thanks for sharing, I'll take a look.

[liqMats]

Hello, unfortunately we have a similar problem. Prisma client $extension with $allModels and $allOperations results in a JavaScript heap out of memory error. But this only happens when declarations is set to true. If declarations are set to false, it works. Using TypeScript 5.1.6.

Thanks for your effort and best regards

[millsp]

Thanks for your reproduction @adamhamlin, I can confirm that it will be fixed.