-
Notifications
You must be signed in to change notification settings - Fork 1
Add @schema decorator to mark namespaces as GraphQL schemas
#1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Note to reviewers: the first commit is just some |
AngelEVargas
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose my personal GH user is already working!
packages/graphql/src/lib/schema.ts
Outdated
| // This will set the namespace for all the decorators | ||
| export const namespace = "TypeSpec.GraphQL"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| // This will set the namespace for all the decorators | |
| export const namespace = "TypeSpec.GraphQL"; |
This should not be needed when using export const $decorators.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out we do need this. When we import schema.js into schema.tsp, the definition must be namespaced in order to match the TypeSpec declaration.
So we have two different paths for namespacing:
export const $decoratorsintsp-index.jssets the namespace explicitly for all decorators when used by external codeexport const namespace =inschema.jssets the namespace when the$schemadecorator is imported directly.
Since these are two independent import paths, they should not conflict.
bb18a3a to
c0fff8a
Compare
| { | ||
| "name": "@typespec/graphql", | ||
| "version": "0.1.0", | ||
| "author": "Microsoft Corporation", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this true?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I mentioned, these package.json updates have been proposed upstream on their own. So I am hoping to get MSFT's input on what should and shouldn't be in package.json as I think it's ultimately up to them.
Until that, I am mostly just copying things over from other packages (primarily openapi3).
c0fff8a to
4581ffb
Compare
swatkatz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a small comment to add the test mode thing as a comment to the test runner.
9b12057 to
f87595e
Compare
Using the `TypeSpec.GraphQL.@schema` decorator on a namespace indicates that the decorated namespace represents a GraphQL schema that should be generated by the GraphQL emitter. Because this allows for multiple schemas to be specified in a TypeSpec source, our test host is reworked to provide a `GraphQLTestResult` corresponding to each schema produced. This commit does not actually implement any emitter functionality, but populates a state map that will be used by the emitter in the future.
f87595e to
5ef2ace
Compare
|
This was merged upstream, so I'm closing out this PR. |
Using the
TypeSpec.GraphQL.@schemadecorator on a namespace indicates that the decorated namespace represents a GraphQL schema that should be generated by the GraphQL emitter.Because this allows for multiple schemas to be specified in a TypeSpec source, our test host is reworked to provide a
GraphQLSchemaRecordcorresponding to each schema produced.This commit does not actually implement any emitter functionality, but populates a state map that will be used by the emitter in the future.