Additional syntax for reusing variable statements

[cometkim]

Hi. I'm experimenting grats on my project, which is using erasableSyntaxOnly flag for Node.js' built-in TypeScript support.

Currently, grats enum can only be used with TS enum and type aliases.

Many TS projects are using plain JS dict with as const to replace TS enum. Or even with Zod

enum MyEnum = {
  Valid = "VALID",
  Invalid = "INVALID",
}

// can be replaced by

const MyEnum = {
  Valid: "VALID",
  Invalid: "INVALID",
} as const;

type MyEnum = typeof MyEnum[keyof typeof MyEnum];
// or with utility type
type MyEnum = Enum<typeof MyEnum>;

So, I'm trying to add support for @gqlEnum with object literals, but there is an issue with type references.

/** @gqlType */
class SomeType {
  /** @gqlField */
  hello: typeof MyEnum[keyof typeof MyEnum];
}

/** @gqlEnum */
const MyEnum = {
  VALID: "VALID",
  INVALID: "INVALID",
} as const;

hello: typeof MyEnum[keyof typeof MyEnum] is not statically referenced anymore. Perhaps grats can provide the Enum utility for it, but it may conflict with user-defined utilities.

My idea is just allowing to override field type by @gqlField directive, e.g.

/** @gqlType */
class SomeType {
  // when typename is preserved
  /** @gqlField {@link MyEnum} */
  hello: typeof MyEnum[keyof typeof MyEnum];

  // or just its name
  /** @gqlField {MyEnum} */
  hello: typeof MyEnum[keyof typeof MyEnum];
}

Syntax is similar to TS' @param (@link for LSP go-to-def support)

Then it unlocks the use cases of grats in real-world TypeScript projects that rely on many type-level utilities.

Thoughts?

[captbaritone]

Sorry I missed this. I think the manual declaration of field types is not ideal since it forces us to have some mechanism to validate the the manually declared field type matches the typescript version.

I wonder if we could do this, where Grats has special understanding of the idiom typeof T[keyof typeof T] at the point of declaration:

const MyEnum = {
  VALID: "VALID",
  INVALID: "INVALID",
} as const;

/** @gqlEnum */
type TMyEnum = typeof MyEnum[keyof typeof MyEnum]

/** @gqlType */
class SomeType {
  /** @gqlField */
  hello: TMyEnum;
}

It's not ideal since it would require Grats to follow T back to its definition in order to extract the names of the enum variants and T might be defined in a different file. This would be the first time Grats would need to parse a TypeScript file that does not include a @gql docblock tag. This means we would either need to parse all files (potentially slow) or parse files lazily as enum types are discovered (adds some considerable complexity).

That said, it feels like the better developer experience.

[cometkim]

Well, I think it's not necessarily an enum-specific issue, but it feels hard to adapt to unless my entire program was built specifically for grats from the scratch.

Annotating types manually isn't the most ideal grats approach, but I think it should at least be provided as an escape hatch to allow for gradual adoption.

For the enum case, since the typeof MyEnum[keyof typeof MyEnum] is very verbose, it's mostly replaced with some utility types, or if they are inherited from a project using zod, maybe z.infer<z.EnumTypr<...>>.. etc.

I would think grats still be useful even with some manual annotations.

[captbaritone]

Maybe we should separate this into two separate issues:

1. Support of inferred Zod types
2. Support for the typeof MyEnum[keyof typeof MyEnum] enum idiom

I think number 2 could be addressed with the proposal I drafted above, but Zod would need a more elaborate solution since it's impossible for Grats to "see" the variants at build time and thus could not infer the schema statically.

For Zod support, one thing I've been exploring is better Pothos interop. The idea being that you could use Grats to define the types which are statically extractable, and Pothos for those which require runtime code to determine and then the two schemas could be stitched together. This is pretty heavyweight for just supporting this one feature but would open up the whole Pothos ecosystem to Grats users and potentially allow Pothos users to adopt Grats syntax in the places where that is more ergonomic.

[cometkim]

I guess zod users are defining enums like GraphQL.js?

const MyEnum = {
  Foo: {
    value: 'Foo',
    description: 'Runtime description',
  },
} as const;

I actually have this style enum definition in my pothos project. And convert it into Zod schema because zod.enum doesn't support description in enum schemas.

[captbaritone]

I've pushed the code for the exploration I did around Pothos here: #210

I expect most Zod (or similar) users are using something like Pothos? https://pothos-graphql.dev/docs/plugins/validation