[WIP] Work on using external modules #158
Conversation
❌ Deploy Preview for grats failed.
|
| - [ ] reenable global validations | ||
| - [ ] "modular" mode? like no full schema, but parts of schema but with full validation by resolving it? | ||
| - [ ] all tests to add fixtures for metadata/resolver map | ||
| - [ ] pluggable module resolution - too many variables there, use filepath by default, let users customize it |
There was a problem hiding this comment.
In theory we only need this path in order to perform validation (is that right?). I wonder if there is a TypeScript API which will let us use the same (or most of) TypeScript's implementation of module resolution. I would need to avoid expecting the file to have a .js/.ts/.mjs/etc extension, but maybe something like that is exposed? I suspect that would be sufficient we could find something like that.
I did see this: https://github.com/microsoft/TypeScript/blob/6a00bd2422ffa46c13ac8ff81d7b4b1157e60ba7/src/server/project.ts#L484
Which could be a good place to start looking.
There was a problem hiding this comment.
I'm not sure any non-ts files are included in how the typescript resolves it. There is also the whole story of "lib" in package.json and stuff like this. Ultimately there is no "well-known" spot for the GraphQL files, so it feels like it all might just break weirdly. I will experiment on this ofc, but I feel that there might not be an easy solution.
| - [ ] Read SDL to actually do validation | ||
| - [ ] reenable global validations | ||
| - [ ] "modular" mode? like no full schema, but parts of schema but with full validation by resolving it? | ||
| - [ ] all tests to add fixtures for metadata/resolver map |
There was a problem hiding this comment.
I'm onboard with this. Happy to have this as a separate PR if you want to merge that first.
TODO.md
Outdated
| - [ ] all imported types (so support interfaces etc) | ||
| - [ ] Read SDL to actually do validation | ||
| - [ ] reenable global validations | ||
| - [ ] "modular" mode? like no full schema, but parts of schema but with full validation by resolving it? |
There was a problem hiding this comment.
Copy pasting from chat:
So I'm realizing it's not rational to expect Grats to own emitting the final GraphQLSchema object if you have external types. Those types will have resolvers that Grats can't know about. So, I think if you use @gqlExternal we must assume that Grats is going to be producing a schema slice, and the consumer will be responsible for stiching it togehter with the other schemas. That could be done with resolver maps or graphql-tools schema merge.
In short, I think as soon as you use @gqlExternal you are implicitly opting into modular mode. We will validate against the full schema, but only emit SDL/resolver maps/GraphQLSchema for the part of the schema that Grats owns.
There was a problem hiding this comment.
I think I have a setup that should work - you can only have gqlExternal in resolver mode and it does full validation, but only generates for local types.
| import { | ||
| SomeType as _SomeType, | ||
| SomeInterface as _SomeInterface, | ||
| } from "./nonGratsPackage.ignore"; |
There was a problem hiding this comment.
One thing I'd like to add eventually is the ability for a fixture file to model multiple files. I did something similar for Relay:
Example: https://github.com/facebook/relay/blob/main/compiler/crates/relay-compiler/tests/relay_compiler_integration/fixtures/client_mutation_extension.input
Implemented here: https://github.com/facebook/relay/blob/main/compiler/crates/graphql-test-helpers/src/project_fixture.rs
I think that would help for tests like this which need to encode relationships between different files.
There was a problem hiding this comment.
Will work in a separate PR, together with test fixes.
|
@captbaritone Could you approve the workflow for me? |
Done |
src/Errors.ts
Outdated
| @@ -607,3 +613,17 @@ export function noTypesDefined() { | |||
| export function tsConfigNotFound(cwd: string) { | |||
| return `Grats: Could not find \`tsconfig.json\` searching in ${cwd}.\n\nSee https://www.typescriptlang.org/download/ for instructors on how to add TypeScript to your project. Then run \`npx tsc --init\` to create a \`tsconfig.json\` file.`; | |||
| } | |||
|
|
|||
| export function noModuleInGqlExternal() { | |||
| return `Grats: @gqlExternal must include a module name in double quotes. For example: /** @gqlExternal "myModule" */`; | |||
There was a problem hiding this comment.
Diagnostics do not need to be prefixed with Grats:
There was a problem hiding this comment.
You do have it in tsConfigNotFound, is that a mistake too?
There was a problem hiding this comment.
Looking pretty good! Left some comments. What would you like to do next? Do you need this to merge to further validate, or should we try to work toward stabilizing it?
I think next steps for that would be:
- Documentation (both for the tag and for the overall use case probably as an additional subpage of this section.
- An example project in the examples directory. Could probably just copy/paste/tweak this one https://github.com/captbaritone/grats/tree/main/examples/incremental-migration
No description provided.