Export TypedDocumentString

[jyasskin]

Right now, if we use documentMode: 'string' the graphql-codegen tool will generate a definition for a TypedDocumentString type into our project. That makes it hard to name the same type from a library like https://github.com/octokit/graphql.js that wants to pass a string through instead of parsing it to a DocumentNode first. It's not obvious that this is the right home for that type, but it seems like the closest existing library.

[jasonkuhrt]

Graffle also needs this:

https://github.com/jasonkuhrt/graffle/blob/ade5a3e61ad536484968880d9218bdcdf4a66ac1/src/layers/0_functions/types.ts#L62-L65

[fpapado]

I have been going down a similar rabbit hole around string-based APIs and standardised types for them (the same octokit issue, in fact!)

I glanced through the original graphql-codegen PR for TypedDocumentString. The decision to inline the type in the output, instead of referencing it from to the core types, seems incidental or at least there was no motivation for it at the time (which is fine 😌).

Having a standard type for string-based libraries (similar to what TypedDocumentNode is for the AST-based APIs) seems like good motivation to me atm.

I have a hunch that we could/should also raise this issue in the graphql-code-generator repository, since that is what would insert the call-sites for this type, and might have more context about its desired shape.

---

Edit: upon further inspection, DocumentTypeDecoration was added to the core types, as a way to support abstractions over both TypedDocumentNode and TypedDocumentString. The utility types point to that idea as well.

It's probably still good to expose a common TypedDocumentString, but wanted to bring this up 💡

[jasonkuhrt]

In Graffle I built its own internal typed document abstraction that sons all three cases: graphql package typed document query, this typed document node, and the typed document string.

If there's interest I may open source it after Graffle is released.

It's not much code, it could easily be contributed back also to Guild repos.

[pleunv]

Also running into issues related to this as I'm using string generation in combination with near-operation-file, and as a result end up with a TypedDocumentString class definition for every file, making it rather complicated to build tooling (such as custom fetchers) around it.