Strict typing with TS
- Dominant language
- TypeScript
- Stars
- 20.3k
- Forks
- 2.1k
- Avg merge
- 44m
- Merged PRs (30d)
- 6
Description
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, if `ChildType` expects `{ foo: string }`, then the result of `ParentType`'s `child` field 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.foo` to be a non-null string cannot be used in a field that defines argument `foo` as optional.
### Scalars
The memory type of both custom and built-in scalars must be tracked. For example, a field with an argument configuration describing `foo` as a `GraphQLString` cannot have a resolver that expects `foo` to be a boolean.
---
Using generics and [conditional types](https://www.typescriptlang.org/docs/handbook/advanced-types.html#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.
Contributor guide
Assessment
This issue has not been assessed yet.