[graphql] Add @typespec/graphql emitter

[FionaBronwen]

Summary

This PR introduces @typespec/graphql, a new emitter that generates GraphQL SDL (Schema Definition Language) from TypeSpec definitions.

Features

• Schema generation: Emit complete GraphQL schemas from TypeSpec models and operations
• Operation types: Support for @query, @mutation, and @subscription decorators
• Interface composition: Use @Interface and @compose for GraphQL interface inheritance
  patterns
• Visibility filtering: Automatic input/output type generation based on @visibility decorators
• Custom scalars: @specifiedBy decorator for custom scalar URL specifications
• Schema customization: @schema decorator for multi-schema scenarios

Architecture

The emitter uses a two-phase approach:

1. Mutation phase: Transforms TypeSpec types into GraphQL-compatible structures using the mutator framework, handling visibility filtering, naming conventions, and type deduplication
2. Render phase: Uses @alloy-js/graphql components to emit the final SDL output

Example

import "@typespec/graphql";

using TypeSpec.GraphQL;

@query
op getUser(@path id: string): User;

@mutation
op createUser(input: User): User;

model User {
  id: string;
  name: string;
  email: string;
}

Generates:

  type Query {
    getUser(id: String!): User!
  }

  type Mutation {
    createUser(input: UserInput!): User!
  }

  type User {
    id: String!
    name: String!
    email: String!
  }

  input UserInput {
    name: String!
    email: String!
  }

Test plan

• Unit tests for all decorators and components (318 tests passing)
• E2E tests covering schema generation scenarios
• Mutation engine tests for type transformation logic

Notes

• This emitter depends on @alloy-js/graphql which is pending publication
• Tracked in GitHub issue GraphQL Emitter Design #4933

[timotheeguerin]

I think because this needs alloy to build it can't really be composite right?

[timotheeguerin]

Last time we talked I think codeowners couldn't be from outside the organization so we'll have to figure out what we want to do here.

[timotheeguerin]

was this meant to be captialized?

[timotheeguerin]

we have the concept of auto decorators comming soon, is that something that would help simplify the implementation of some of your decorators? #10197

[timotheeguerin]

The way those decorators are implemented kinda goes against the philosphy of those decorators(shouldn't really have to check the .decorators list unless there is a feature gap in the compiler)

Any reason to do that over using the stateMap/stateSet(and potentially as mentioned in another comment the upcomming auto decorators?)

[timotheeguerin]

you don't need to export(and I would recommend against now) the namespace, the $decorators just takes care of it.

[timotheeguerin]

I see the $lib contains a few error diagnostics but you don't have any onValidate. Ideally we'd like to have emitters try to not emit erors. In your care this is of course both a library providing protocol bindings and an emitter but it would be ideal if the protocol validation was able to be done in the $onValidate. This would ensure that the spec is checked regardless of if the emitter is run

[timotheeguerin]

we also have the concept of a dry-run compatible emitter, this is a flag you can set in the config to say that if --dry-run is passed your emitter can be run and it will respect this flag(not write anything but still report the diagnostics)
If that is possible with the architecture of the emitter we should do that. (Doesn't also need to be done right now)

[timotheeguerin]

we should also add the emitter to the website