Feature request: handling not implemented resolvers

[felamaslen]

Before migrating to grats, when we used a schema-first approach, we used a custom directive called @notImplemented, to mark fields as as not having been implemented yet.

It would work like this: add @notImplemented to a given field, and the field will:

• Have a description appended during introspection, indicating that the field is not implemented yet
• Throw an error if you attempt to resolve it

With code-first schema development (i.e. grats), this becomes redundant, because you need to define the function body of every resolver in any case, and unless you cast as the return type, the body will just throw an error (at least that has been our approach):

/** @gqlField */
export async function myField(): Promise<Int> {
  throw new Error('Not implemented');
}

This works well, except it is opaque to end-users that this field is not implemented, until you attempt to resolve it. It would be useful for grats to automatically detect that the field has not been implemented, and add documentation or set this information in the extensions somewhere.

Proposal

I suggest that for a given field resolver function, during schema generation, if the function's AST node contains a single call to throw new Error(...), that the field be marked as not implemented.

Alternatively, if we can deduce that the ReturnType of the resolver function is never, that would be a more robust check.

[captbaritone]

I think there would be quite a bit of value in a spec-defined directive of @notImplemented or @experimental to mirror @deprecated but since no such concept exists in GraphQL or in TypeScript I'm not sure Grats should be in the business of trying to define it.

However, I wonder if you could achieve your desired outcome with a custom ESLint rule which looks for functions/methods with @gqlField whose bodies are just one throw expression and then checks that they also have a @gqlAnnotate notImplemented on them. You could probably even make the rule fixable.

[felamaslen]

Sure, this can be implemented as a lint rule. But the lint rule would then have to know about grats-specific logic.

[captbaritone]

I think a custom lint rule here should work well, and likely could be trivially written by an AI prompt, so I'll mark this as closed.