P
Prisma•3mo ago
Gregersen

Anyone else seeing "The inferred type cannot be named..." errors after 6.16 update?

I was updating our Prisma from 6.15 to 6.16, and decided to try out the new rustfree engine now that its GA. However, upon doing so, almost all of our tRPC routes starts throwing errors: 
The inferred type of 'X' cannot be named without a reference to '../../node_modules/@spaak/db/generated/client/client'. This is likely not portable. A type annotation is necessary.ts(2742)
The inferred type of 'X' cannot be named without a reference to '../../node_modules/@spaak/db/generated/client/client'. This is likely not portable. A type annotation is necessary.ts(2742)
Our tRPC setup is somewhat large and complex (320 handlers, with around 20-30 routers), looking roughly like this: 
export const observeRouter = createTRPCRouter({
  observation: observationRouter,
  tabFolder: tabFolderRouter,
  developer: developerRouter,
  pending: observePendingRouter,
  statistics: observeStatisticsRouter,

  getObservationDocumentIds: featureProtectedProcedure(
    ApplicationFeature.OBSERVE,
  )
    .input(ZGetObservationDocumentIdsInput)
    .mutation(async (opts) => {
      const handler = await importHandler(
        namespaced("getObservationDocumentIds"),
        () => import("./getObservationDocumentIds.handler"),
      );

      return handler(opts);
    }),
    ...
export const observeRouter = createTRPCRouter({
  observation: observationRouter,
  tabFolder: tabFolderRouter,
  developer: developerRouter,
  pending: observePendingRouter,
  statistics: observeStatisticsRouter,

  getObservationDocumentIds: featureProtectedProcedure(
    ApplicationFeature.OBSERVE,
  )
    .input(ZGetObservationDocumentIdsInput)
    .mutation(async (opts) => {
      const handler = await importHandler(
        namespaced("getObservationDocumentIds"),
        () => import("./getObservationDocumentIds.handler"),
      );

      return handler(opts);
    }),
    ...
This is a mix of nested routers and new routes, to organize our endpoints into namespaces and meaningful folders, keeping things scoped how we want. This observeRouter doesn't show the error if I comment out all the handlers, and leave only the routers. What's strange is, that none of the handlers are showing any errors. Is anyone else seeing this? I am not sure how this relates to Prisma at all, but curious to hear if anyone else has experienced this.
6 Replies
Prisma AI Help
Prisma AI Help•3mo ago
You chose to compile with the bot. One moment while I piece together your answer… Short answer: yes, others have hit similar TypeScript “inferred type cannot be named” (TS2742) problems when upgrading Prisma and/or switching engines, especially in setups that re-export Prisma Client from a separate package and use tRPC. What we know from the sources: - Re-exporting Prisma Client types across package boundaries (monorepo “db” package) often triggers TS2742, and users worked around it by: - Generating the client to a custom output path and importing from that path directly in dependents. [export * error].
- Avoiding wildcard re-exports, and instead importing only the types you need (or using export type { Model } from "..."). This reduced the error surface, though it’s cumbersome with many models. [export * error].
- Note: This commonly shows up alongside tRPC because of heavy type inference across package boundaries. [export * error]. - Similar “cannot be named” and declaration-emit issues also occurred with newer client outputs and TypeScript configs (declaration/composite), and were fixed in subsequent Prisma releases; pinning the generator/output or adjusting TS settings sometimes helps. [composite issue; new generator typecheck]. Practical steps to try: 1. Generate client to a local path and import directly: - In schema:
     generator client {
       provider = "prisma-client-js"
       output   = "../generated/client"
     }
     
     generator client {
       provider = "prisma-client-js"
       output   = "../generated/client"
     }
Then import from that generated path in your API package, not via re-exported “@prisma/client”. [export * error]. 2. Avoid export *; prefer explicit type exports: - export type { User, Post } from "../generated/client"; [[export * error](https://github.com/prisma/prisma/issu es/27817)]. 3. If TS still complains, add explicit type annotations on your tRPC routers/procedures to stop TS from needing to name inferred types across package boundaries. [export * error]. 4. If you use declaration/composite builds, ensure you’re on a Prisma version where recent declaration-related issues are fixed (e.g., similar problems were addressed after 6.6.0). [composite issue; new generator typecheck]. I don’t see a documented minimum tRPC version requirement in the sources. The pattern points to TS/re-exports/inference rather than a specific tRPC version constraint.
Gregersen
GregersenOP•3mo ago
I have tried re-exporting a broad * to maintain backwards compatability as so: 
// Re-export everything from the server-side Prisma client for full compatibility
export * from "../generated/client/client";
// Re-export Prisma namespace for backwards compatibility (Prisma.X usage)
// Note: We use the client's Prisma namespace to get SQL utilities like Prisma.sql, Prisma.raw, etc.
export * as Prisma from "../generated/client/internal/prismaNamespace";
// Re-export everything from the server-side Prisma client for full compatibility
export * from "../generated/client/client";
// Re-export Prisma namespace for backwards compatibility (Prisma.X usage)
// Note: We use the client's Prisma namespace to get SQL utilities like Prisma.sql, Prisma.raw, etc.
export * as Prisma from "../generated/client/internal/prismaNamespace";
But it doesn't seem like it's doing much difference. I have already configured the prisma-client, as instructed by the documentation. What's more confusing is that tRPC doesn't seem to use Prisma types in the cases where I'm seeing errors. But for the sake of having nothing else to go on, let's continue diving into how the changed exports, might be the culprit. How could I determine this? Given that I am already doing a * export to maintain backwards compatability, how can I go about debugging my trpc package (we're in a monorepo, where "db" and "trpc" are separate packages), and figure out where things go wrong?
Prisma AI Help
Prisma AI Help•3mo ago
🤔 Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly. In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.
Gregersen
GregersenOP•3mo ago
Narrowing in the issue, it seem that all the handlers in which we directly do a return await ctx.db.someModel.deleteMany or updateMany or createMany, effectively does mapping to Prisma.BatchPayload, now needs an explicit return type for things to work. Similarly a lot of the routers were affected, needing return types too. I am not sure this is the final solution, but working through it now. It seems to be related to Prisma, in that Prisma changes the export structure with the generated model. It seems that the hurdle is that tRPC routes can't infer return types of our handlers, because the internal types of prisma were moved, see this error for example: 
The inferred type of 'observeRouter' cannot be named without a reference to '../../../node_modules/@spaak/db/generated/client/internal/prismaNamespace'. This is likely not portable. A type annotation is necessary.ts(2742)
The inferred type of 'observeRouter' cannot be named without a reference to '../../../node_modules/@spaak/db/generated/client/internal/prismaNamespace'. This is likely not portable. A type annotation is necessary.ts(2742)
This is from within the trpc package, so it's trying to resolve the type from within node_modules, which it shouldn't be. However, I am not sure if it is possible to export the Prisma types in a way that can "fix" this type inference. Is it? Did it previously create some sort of d.ts file in the node_modules folder, that our trpc routes was relying on? If yes, is it possible to mimic this behaviour by creating a file that forwards these again? The file itself warns against being directly imported anywhere. If not, what options do I have? It seems that if I re-export everything from the internal prisma namespace: 
export * from "../generated/client/client";
export * from "../generated/client/internal/prismaNamespace";
export * from "../generated/client/client";
export * from "../generated/client/internal/prismaNamespace";
Then things work. This is in part due to bad export practices previously, where everything would be exported. I know we shouldn't be doing this, it was a decision made before I joined, so I'm trying to get us as close as I can, to a "better place". These exports seem to have fixed my issues, but I reckon it's symptom treatment. I hope someone else can use this. !SOLVED
Nurul
Nurul•3mo ago
We did a patch release version 6.16.1, can you check if you get the same error in this version as well?
Gregersen
GregersenOP•3mo ago
It looks like this absolutely fixes it! Thank you 🙏

Did you find this page helpful?