Is it possible to use enum types with the Errors plugin?

[garth]

Using the Errors plugin, I'm trying to throw errors that have an ErrorCode enum included:

export enum ErrorCode {
  EMAIL_IN_USE,
  SIGN_IN_FAILED,
}

export class ErrorWithCode extends Error {
  public code: ErrorCode
  constructor(code: ErrorCode, message: string) {
    super(message)
    this.code = code
  }
}

builder.enumType(ErrorCode, { // this line throws the error
  name: 'ErrorCode',
})

builder.objectType(ErrorWithCode, {
  name: 'ErrorWithCode',
  fields: (t) => ({
    code: t.expose('code', { type: ErrorCode }),
    message: t.exposeString('message'),
  }),
})

But when I run the server this causes an error:

[INFO] 00:16:24 ts-node-dev ver. 2.0.0 (using ts-node ver. 10.9.1, typescript ver. 4.8.3)
TypeError: Cannot read properties of undefined (reading 'enumType')

Are enums in error types supported?

[garth]

I tried running the build via esbuild and swc and they gave different errors that hinted at cyclic dependency issues.

After quite a bit of trial an error, it seems that moving the enums and classes out into separate files has resolved the issue.

[hayes]

Circular imports are a real pain. Something that can help a bit here is to define the builder in a relatively isolated file that just sets up the builder and has as few imports as possible (only Pothos and it's plugins, or other files without any imports, like something setting up your db driver). You may end up needing to import a lot of types depending on the plugins you use, these should be imported with import type { Foo } from ... so the imports are removed at runtime. Pothos tries to solve a lot of circular import issues related to refs for different fields and types by wrapping definitions for fields in functions who's execution is deferred, but if the builder itself is defined in a circular import, there isn't much Pothos can do to help

[garth]

Thanks for taking the time to reply!

I pretty much followed the complex example for the layout. But maybe I'm not being so careful with import type I will be more mindful about that in future.

https://github.com/garth/headule/tree/master/packages/api/src

[hayes]

There is an eslint plugin that can identify circular imports, might be helpful for catching/debugging this kind of issue in the future. It can be kind of a pain though because a lot of the time, circular imports end up being okay depending on how the imports are used

[hayes]

Looking at your repo, it looks like you import ErrorWithCode into builder.ts, and previously imported builder into error.ts, which would cause this issue. I think in that case, if you had done an import type for ErrorWithCode that probably would have fixed the issue in this case

[garth]

I found a few helpful eslint plugins/rules that I have applied.

npm packages: eslint-plugin-import & eslint-import-resolver-typescript

Applying the recommended eslint plugin config + the following rule seems to address import type issues as well as cyclic checks.

'@typescript-eslint/consistent-type-imports': ['warn', { prefer: 'type-imports' }],