grats

grats copied to clipboard

Here's a repo that runs repo and documents some warts and workarounds.

What I have found so far:

• Scalars provided by Grats (import { Float, Int, ID } from "grats") are importable just fine, but seems like the docblocks aren't reachable.
  • Kinda makes sense: these imports are importmaps managed by Deno; I'm guessing Grat's Typescript compiler can't locate the actual file where the scalars are defined, the file containing the scalars' dockblocks.
  • A not-so-terrible workaround is to "vendor" the scalar definitions, so they are fully accessible by Grat's (see schema.ts in this repo).
• Module remapping must be done carefully to ensure a single graphql version is pulled, otherwise graphql itself will complain.

Module remapping must be done carefully to ensure a single graphql version is pulled, otherwise graphql itself will complain.

This is also a problem generally, but maybe easier to hit in deno? One thing we might want to do in Grats is move toward a model where graphql is a peer dependency. We are tightly coupled with that package so our support range would be narrow, but it might help avoid the very confusing failure mode where you have two instances.

I think a good next step here would be to add an example deno project here that encodes these issues. Even if it's not a perfectly smooth setup today, it would document the existing workarounds and let us at least capture the situation. As/if we are able to improve that situation, we would be able to update that example as well.

@mandx , If you're interested in working on that, feel free to submit a PR, but no pressure.

(Still tinkering on this) Had to use module remapping to force Grats to use the same (newer) Typescript version used in Deno (v5.2.2 at this time) to be able to make it generate a schema from classes/types spread across several TS modules.

The example repo at this time has all resolver classes in a single module and it works fine; but as soon as I did a little refactoring and split the code into some modules, Grats started erroring on "this types are not tagged with @gqlType, etc".

Would the TS version be fixed if we switched to making TypeScript a peer dependency (with constrained versions?)

The problem specific to Deno is just the version used. I think after v5, TS got smarter about module resolution, which might explain why Grats works with this Deno codebase, but it doesn't with TS v4.9 (the version Grats pulls at the moment).

I'm not sure if the concept of "peer dependency" applies to Deno, but in general, yeah, I think Grats does need to declare typescript as a peer dependency; this would make sure that all code is checked against a specific version, also, TS is a heavy dependency; I definitely wouldn't want 2+ TS versions in my node_modules directory.