Error while generating for big Prisma schema about typegraphql-prisma

[dcapotos]

I'm having the same problem however my call stack size exceed error is occuring at
node_modules@ts-morph\common\node_modules\typescript\lib\typescript.js:100638:30)

This is for a very large database with a schema file that is over 6000 lines long with many models.
I can not provide the schema because this is private to my company, however I imagine this can be reproduced by creating a schema file filled with dozens of generic models. I can tell you that none of the models in my schema had any relations to each other, if that helps.

This only happens if I do NOT specify an output file in schema.prisma. (is this generating transpilled files to node_modules?)

This works
generator typegraphql { provider = "typegraphql-prisma" output = "../src/generated/typegraphql-prisma" }

This does not:
generator typegraphql { provider = "typegraphql-prisma" }

I noticed that as I cut the schema file down to about 3800 lines, it suddenly works.
As I added new models, one by one, each followed by a generate command, it eventually hit the Maximum call stack size exceeded error.

My best guess would be that either the typegraphql generator or typescript has some recursive calls going on that reached an upper limit based on the number of models/schema size.

[Nayir]

I'm facing this issue too with a large schema, using the output folder outside node_modules too.
Not working with node 15+ but working with node 14.

By the way, I'm not really confortable with decorators, but I was wondering if there is a way to remove typegraphql / typegraphql-prisma dependencies from the build files (omitting the decorator ?), this way I think the problem can be solved. @MichalLytek WDYT , there is a way to do this ? I'm ready to help you working on it if necessary of course.

[mattkindy]

I managed to transpile my code and use node directly. I set my stack-size option to 1200 for now, and that's enough to get past the error for now. I don't think this is a viable long-term option, though, so I'm continuing to investigate.

[MichalLytek]

Without reproduction I'm not able to do anything 😞

You can try to generate source code to your repo folder - check docs for more info.

[Hebilicious]

Unfortunately I can't provide you the full schema, but there's nothing really fancy about it besides it's length (3200lines).
What could I provide that would be helpful ?

[MichalLytek]

@Hebilicious
You can remove half of your schema and try again. If won't fail, then try with the second half. Maybe it's an issue with some cyclic references, not related to 3200 lines long schema.

If you are unable to isolate the schema part, you can try to recreate or generate the big prisma schema file.
Maybe you are allowed to replace the names with a, b and abc? 😉

[Hebilicious]

@MichalLytek
Thanks for the answer 👍
This is a schema introspected from a large production database. Isolating would be a possibility, but I was wondering if the issue was related with your package or something else. I'll try to do more investigating.

[rossinicolas]

i had a same issue a few days ago and i found that the problems appears after i update the typescript module to version 4.0, if i keep using version 3.9.7 there aren't a problems.
I have a prisma model made by introspection for about 122 tables and has 1650 lines.

[MichalLytek]

I think it might be an issue with ts-morph which is responsible for generating the code files.

@Hebilicious @rossinicolas
Are you using the default approach with generating transpilled files to node_modules?
Or you emit source code TS files in your repo folder?

[omar-dulaimi]

I'm facing this issue too with a schema around 1500 lines. The output folder is outside node_modules.

[MichalLytek]

@Nayir If you want typegraphql generator without decorators and typegraphql, maybe you need to find a different tool like nexus-prisma?

[JeremyNoh]

Hi everyone, 🙂

I'm also trying the generator with a large prism schema (489 models, over 9000 lines),
I do not understand ... I have no warning, no error, but my output folder is still empty. 🥲

my schema

datasource db {
  provider = "sqlserver"
  url      = env("DATABASE_URL_ADN_DIAG")
}

generator client {
  provider           = "prisma-client-js"
  output             = "./generated/clientDiag/type-rest"
  emitTranspiledCode = "true"
}

generator typegraphql {
  provider           = "typegraphql-prisma"
  output             = "./generated/clientDiag/type-graphql"
  emitTranspiledCode = "true"
}

My terminal

I tried different options like "emitTranspiledCode" and of course "output", but still empty..

(Knowing that the "prisma-client-js" works well.
And when I cut my schema with only 15 models it works wonderfully )

Do you have a solution for me?

Thanks a lot for your answer 🤗

[MichalLytek]

489 models would be like 5000 classes or more, I don't think it's doable to generate it in reasonable time 😕

[JeremyNoh]

Thank you for your quick response, 😁

I found a solution to avoid database-wide introspection, and thus reduce unnecessary relationships:

I created a user on my database
and I only gave him access to part of the database

[mattkindy]

Just want to add more information to this thread since this is causing us problems at a very inopportune time --

I had this working in our project (under a very specific set of conditions -- node 14.18.3, 8+ GB RAM to build, schema with 149 models, generating transpiled code, running with ts-node) for a few weeks. Generation would take somewhere around 5-6 minutes (not surprising).

Recently, our re-introspected database schema (we're migrating from Prisma 1 -> 2+) increased from the 149 models I just mentioned to 164 models. Now we hit the maximum call stack error at runtime (on import of generated typegraphql classes). Nothing else changed (we are using package-lock.json etc.).

From the new schema, there are about ~14k javascript files generated, Breakdown:

• resolvers/inputs: ~8k
• resolvers/crud: ~4k
• resolvers/outputs: ~1k
• resolvers/relations: ~700
• enums: 167
• models: 165

The trace I get:

<rootDir>/node_modules/@generated/type-graphql/resolvers/inputs/UserCreateWithoutUser_BInput.js:582
    TypeGraphQL.Field(_type => TradeFlexDataCreateNestedManyWithoutUserInput_1.TradeFlexDataCreateNestedManyWithoutUserInput, {
                ^
RangeError: Maximum call stack size exceeded
    at Object.<anonymous> (<rootDir>/node_modules/@generated/type-graphql/resolvers/inputs/UserCreateWithoutUser_BInput.js:582:17)
    at Module._compile (internal/modules/cjs/loader.js:1085:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:12)
    at Module.require (internal/modules/cjs/loader.js:974:19)
    at require (internal/modules/cjs/helpers.js:93:18)
    at Object.<anonymous> (<rootDir>/node_modules/@generated/type-graphql/resolvers/inputs/UserCreateOrConnectWithoutUser_BInput.js:6:40)
    at Module._compile (internal/modules/cjs/loader.js:1085:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)

Line 582 in question:

    TypeGraphQL.Field(_type => TradeFlexDataCreateNestedManyWithoutUserInput_1.TradeFlexDataCreateNestedManyWithoutUserInput, {
        nullable: true
    }),

I've attached the stack trace written out to 1000 lines. You can see it's mostly a ton of resolver code.
long-stack-trace.log

I also tried (just to see what changes):

• simpleResolvers = true: Same problem
• emitOnly = "enums,models,inputs,outputs": Same problem, different class
• emitOnly = "enums,models,crudResolvers": Not surprisingly, same problem
• emitOnly = "enums,models,relationResolvers": Strangely, this seems to generate more files? But it doesn't run into the original error. Instead something else:

This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
Error: Some errors occurred while generating GraphQL schema:
  Type Query must define one or more fields.
Please check the `details` property of the error to get more detailed info.
    at Function.generateFromMetadata (<rootDir>/node_modules/type-graphql/dist/schema/schema-generator.js:20:23)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async buildSchema (<rootDir>/node_modules/type-graphql/dist/utils/buildSchema.js:10:20)
    at async generateSchema (<rootDir>/src/schema.ts:10:14)
    at async startServer (<rootDir>/src/index.ts:14:18)

More details:

• We are using ts-node to invoke our typescript apollo-server application (no difference if we use transpileOnly option or not for this error)
• We are Importing the transpiled javascript directly
• Am running in docker (image based on node:14.18.3, nothing special), but can reproduce this on bare metal
• tsconfig.json:

{
  "compilerOptions": {
    "baseUrl": "./src",
    "target": "ES2020",
    "module": "CommonJS",
    "moduleResolution": "node",
    "lib": ["es2018", "esnext.asynciterable"],
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "outDir": "./dist",
    "rootDir": "./src",
    "esModuleInterop": true
  },
  "exclude": ["**/node_modules"]
}

• dependencies / devDependencies:

  "dependencies": {
    "@prisma/client": "~3.14.0",
    "@types/graphql-fields": "^1.3.4",
    "apollo-server": "^3.6.5",
    "apollo-server-core": "^3.6.7",
    "class-validator": "^0.13.2",
    "graphql": "^15.8.0",
    "graphql-fields": "^2.0.3",
    "graphql-scalars": "^1.17.0",
    "jsonwebtoken": "^8.5.1",
    "reflect-metadata": "^0.1.13",
    "ts-node": "^10.7.0",
    "tslib": "^2.3.1",
    "type-graphql": "^1.1.1",
    "typescript": "^4.6.3"
  },
  "devDependencies": {
    "nodemon": "^2.0.15",
    "prisma": "~3.14.0",
    "rimraf": "^3.0.2",
    "typegraphql-prisma": "0.20.3"
  }

[revero-doug]

@MichalLytek @Hebilicious can we get an update in the description of this issue and/or the labels applied? Seeing a "high priority bug" open for ~2 years is, in my view, a (perhaps superficial) red flag when evaluating pulling in this package as a dependency, and I wonder if this is still truly a high priority bug having read through some of the comments. It seems as though if the workarounds and limitations are clearly documented, this bug could be downgraded and/or split out into more targeted issues.