[BUG] Fails at runtime when a resolver is missing in a mapper

[olalonde]

I noticed that the generated types for mappers have all fields marked as optional so if you delete one of them, typescript won't notice but it will fail at runtime. Is this intended?

For example:

type Vehicle {
  id: ID!
  telemetryLogs: [TelemetryLog!]!
}

I have this mapper:

Vehicle.ts

import type { VehicleResolvers } from "../../types.generated.ts";
export const Vehicle: VehicleResolvers = {
  telemetryLogs: async (_parent, _arg, _ctx) => {
    /* Vehicle.telemetryLogs resolver is required because Vehicle.telemetryLogs exists but VehicleMapper.telemetryLogs does not */
  },
};

I am able to completely remove the telemetryLogs property:

import type { VehicleResolvers } from "../../types.generated.ts";
export const Vehicle: VehicleResolvers = {
  // telemetryLogs: async (_parent, _arg, _ctx) => {
    /* Vehicle.telemetryLogs resolver is required because Vehicle.telemetryLogs exists but VehicleMapper.telemetryLogs does not */
  // },
};

... it will still compile fine with typescript. However, since latestTelemetry is non nullable in my GraphQL schema, it will fail with a runtime an error when I query it.

In the generated.types.ts file

export type VehicleResolvers<ContextType = GraphQLContext, ParentType extends ResolversParentTypes['Vehicle'] = ResolversParentTypes['Vehicle']> = {
  id?: Resolver<ResolversTypes['ID'], ParentType, ContextType>;
  telemetryLogs?: Resolver<Array<ResolversTypes['TelemetryLog']>, ParentType, ContextType>;
  __isTypeOf?: IsTypeOfResolverFn<ParentType, ContextType>;
};

The problem is that telemetryLogs?: should really be telemetryLogs:. Isn't it?

[eddeee888]

Hello @olalonde , apologies, I couldn't get to this earlier

The generated type (VehicleResolvers) is correct, in the sense that GraphQL allows us to choose not to declare a resolver.
However, in practice, it'd error. We want to avoid runtime error like you said.

This is where Server Preset comes in: it hints that to avoid runtime error, we must implement Vehicle.telemetryLogs resolver, and creates the resolver skeleton for us. 🙂

[olalonde]

In what sense does GraphQL allow us to choose not to declare a resolver? Doesn't the GraphQL spec require telemetryLogs: [TelemetryLog!]! to be defined because of the ! annotations?

I know that the generator does create the missing resolvers' code but it would be even better IMO if the type system would detect when a required resolver is missing (e.g. in case I accidentally remove the generated code at some point). For a resolver to be considered as required it should satisfy those two properties:

• the parent type mapper doesn't return it (it seems your code already knows about this since it correctly generates the resolver code for missing properties on the mapper)
• the property is marked as required in the GraphQL schema (!)

e.g.:

type Vehicle {
  id: ID!
  requiredProp: SomeDataType!
  optionalProp: SomeDataType
}

=>

export type VehicleResolvers<ContextType = GraphQLContext, ParentType extends ResolversParentTypes['Vehicle'] = ResolversParentTypes['Vehicle']> = {
  id?: Resolver<ResolversTypes['ID'], ParentType, ContextType>;
  requiredProp: Resolver<ResolversTypes['SomeDataType'], ParentType, ContextType>;
  optionalProp?: Resolver<ResolversTypes['SomeDataType'], ParentType, ContextType>;
  __isTypeOf?: IsTypeOfResolverFn<ParentType, ContextType>;
};

Is there a technical reason why this is more difficult to do than I imagine perhaps?

[eddeee888]

In what sense does GraphQL allow us to choose not to declare a resolver? Doesn't the GraphQL spec require telemetryLogs: [TelemetryLog!]! to be defined because of the ! annotations?

Let's say this is your schema:

type Query {
  vehicle(id: ID!): Vehicle
}

You have a choice to resolve vehicle's telemetryLogs inside Query.vehicle. This is bad for many reasons, but you could.
If you chose to do it this way, you don't have to declare Vehicle.telemetryLogs at all:

const vehicle: QueryResolvers["vehicle"] = (_, { id }, { db }) => {
  const vehicle = db.vehicle.find({ id });
  const vehicleTelemetryLogs = db.telemetryLogs.findByVehicleId({ id });

  return {
    id: vehicle.id,
    telemetryLogs: vehicleTelemetryLogs
  }
}

Vehicle.telemetryLogs could be undefined because the data resolved in Query.vehicle can be passed through directly to the response.

---

Is there a technical reason why this is more difficult to do than I imagine perhaps?

Happy to share how it works!
The base type (generated by typescript-resolvers plugin) uses GraphQL AST. This process is fairly fast.
The Server Preset uses TypeScript AST to run static analysis, to check the differences between mapper interface vs generated base type. This process is a bit slower, so it is kept inside Server Preset to avoid impacting the base experience.

We have two ways to enforce whether a resolver is required here:

1. By making the base generated type required (your proposal). This is possible, however:
   • 👎 it requires looking into the base generated type using TypeScript AST, mutate type generated by typescript-resolvers plugin, which could be hard to test and debug.
   • 👎 The TypeScript error could be cryptic when a resolver is required
2. By injecting missing resolvers on running codegen:
   • 👍 Does not mutate generated types (which is technically correct as explained in the section above)
   • 👍 Allows adding comment to explain why a resolver is required. This is useful for users because it (1) creates a skeleton so there's less typing and (2) helps beginners understand why a resolver is required.

So, it is not particularly hard, but it was deliberately done this way to keep the correctness of the types and improve explanability.

I know that the generator does create the missing resolvers' code but it would be even better IMO if the type system would detect when a required resolver is missing (e.g. in case I accidentally remove the generated code at some point).

If you run codegen again, the resolver will be generated and injected. If it doesn't do so, please let me know.
Generally, I recommend running codegen in CI to ensure your types are always up-to-date with the schema. And if you use Server Preset, it'd catch missing resolvers.