Jordan Eldredge

I took a stab at migrating a TypeGraphQL app to Grats this evening, and found that not having support for positional args made it rather difficult. Ideally, one could just:...

Completed in https://github.com/captbaritone/grats/pull/149

The only escape hatch I can think of would be monkey patching the GraphQLSchema instance created by Grats.

An observation: Probably however we solve this, it should work the same as `resolveType` on abstract types, which is another similar missing feature in Grats today.

I really appreciate hearing what felt intuitive given your existing experience with Grats! That's very helpful. I love that this approach does not require any additional syntax, however there are...

## Object Export Options What if defining a scalar was done by annotating an exported object literal that defined the parse/serialize methods? ```ts /** @gqlScalar **/ export const Date =...

Here’s another thought. Perhaps we keep the mental model that GQL tags map 1 to 1 with SDL constructs. Defining a JavaScript executor, of course, requires more than this, as...

I'm proceeding with the `getSchema` approach. One interesting issue is that the types exposed by graphql-js for serialize/parseValue are needlessly vague. What's worse, it seems to be intentional: https://github.com/graphql/graphql-js/issues/3451#issuecomment-1008114612 Probably...

I've documented the current work-around here: https://github.com/captbaritone/grats/commit/561a9142234ee976c7bfc0a91f5fdcd4e8875c03

Looking at the types in `graphql-js` a bit more fully to see how our types should differ from theirs: Here's basically what graphql-js has, and why: ```ts type Scalar =...