All document types are any

[a-type]

I've been successfully using gql.tada in a rather complicated monorepo, more or less crossing my fingers the whole time.

Recently I updated several dependencies, including gql.tada and Typescript, as well as upgraded to Node 22 (from 18). After the dust settled, all my graphql(...) calls return any, and I can't figure out why.

My monorepo structure consists of one server (with the GraphQL endpoint) and many different frontend apps which consume the API. So, my goal is to have all of these app sub-projects able to validate and type their GraphQL documents against the same API schema.

Here is the repo.

My API auto-generates a schema file, so that's taken care of. I've tried many different approaches to integrating gql.tada, but for the sake of (I hope) reducing accidental complexity, I've just refactored so that each app/package which creates gql documents has gql.tada as a direct dependency and configuration in tsconfig.json which points to the shared schema file (packages/graphql/schema.graphql) and outputs the env typings to the local src directory. All of this appears to work and the typings are written to file. See the web directory for a live example.

Importing graphql, the function itself has types (it's not any or unresolved). But no matter what doc I pass in, it returns any.

Additionally, I use ESM modules/resolution exclusively. I've seen in the past how, if the typings of a library aren't ESM compatible, it's silently failed to any somewhere downstream before. But as I said, gql.tada was functional for me up until this recent dependency upgrade fest. And downgrading gql.tada back to 1.8.2 (where I was before) doesn't seem to help.

[a-type]

I think I found the issue here, which is that somewhere along the way the pnpm linking behavior I had been relying on for transitive dependencies seemed to either have changed, or whatever shaky truce I had was broken.

Transitive types were not being resolved by editor Typescript because they were not hoisted or otherwise accessible from the first-level dependency modules. I "fixed" this by enabling shamefully-hoist=true in my .npmrc. That seems to have solved this issue.