mike-marcacci
commented
4 years ago As a tiny demonstration of one piece of this, consider this partial TS reimplementation of the graphql-js codebase:
// This is a reimplementation of GraphQLScalarType with generics.
class GraphQLScalarType<TInternal, TExternal> {
internal: TInternal;
external: TExternal;
}
// Here are two of our built-in scalars.
const GraphQLString = new GraphQLScalarType<string, string>();
const GraphQLInt = new GraphQLScalarType<number, number>();
// We want to extract the type, using the configuration object in the `type`
// field as our source of truth. If it's set to `GraphQLString`, then we want to
// make sure that the resolver in fact returns a string.
//
// In the real-world, there are many more factors (complex types, nullable
// types, lists, default resolvers, async resolvers, etc) but this is just a
// minimal example.
type FieldConfig<TConfig> = TConfig extends GraphQLScalarType<
infer TInternal,
any
>
? {
type: TConfig;
resolver: () => TInternal;
}
: never;
// Our dummy reimplementation of `GraphQLObjectType` can infer the field types
// from the config object, so we don't actually have to pass in this generic
// parameter.
class GraphQLObjectType<
T extends {
[K in keyof T]: T[K] extends { type: infer V } ? FieldConfig<V> : never;
}
> {
constructor(config: { name: string; fields: T }) {
// Setup happens here...
}
}Using this, it's perfectly legal to create the following Person type:
const Person = new GraphQLObjectType({
name: "Person",
fields: {
name: { type: GraphQLString, resolver: () => "hello" },
age: {
type: GraphQLInt,
resolver: () => 12345
}
}
});However, if we change the age resolver to return a string, our TypeScript will report an error, and prevent us from ever shipping bad code!
xialvjun
koistya
Janpot
MatthiasKunnen
dotansimha
pspeter3
zachasme
jdpst
eezing
Looks like 
yaacovCR
CSNWEB
josiah-roberts
This issue is to track a set of goals for type safety in TypeScript. In experiments, I have confirmed that all of these should be possible. While the increased verboseness has some ergonomic cost, the resulting type safety is overwhelmingly worth it in my opinion.
Object Types
For every field of a
GraphQLObjectType, the resolver (including a "default resolver") must return a value compatible with the "source" of the field's GraphQL "type". For example, ifChildTypeexpects{ foo: string }, then the result ofParentType'schildfield cannot be{ foo: 123 }or"foo".Arguments & Input Types
The configuration of all defined arguments and input types must be checked against the types used in a resolver. For example, a resolver expecting
args.footo be a non-null string cannot be used in a field that defines argumentfooas optional.Scalars
The memory type of both custom and built-in scalars must be tracked. For example, a field with an argument configuration describing
fooas aGraphQLStringcannot have a resolver that expectsfooto be a boolean.Using generics and conditional types, I have been able to demonstrate that each of these is possible. However, as these effect the type signature of all primitive GraphQL components, there are a substantial number of changes across the repo. At one point I had opened a PR to DefinitelyTyped that gave partial support for strict typing of arguments, but the change was breaking (from the perspective of types) and I was too busy to effectively convey the significance before the PR was auto-closed.
As this is a natural time to implement this kind of change (during an existing push to re-type the whole codebase), I'm going to open a PR that converts the entire repo to TS in a way that accomplishes these goals. I'll begin my changes as soon as #2139 gets merged and there's a feature lock for 15.