Skip to content

Add Alloy infrastructure, context system, and field components#77

Open
FionaBronwen wants to merge 3 commits into
fionabronwen/graphql-statemap-to-decoratorsfrom
fionabronwen/graphql-alloy-foundation-v2
Open

Add Alloy infrastructure, context system, and field components#77
FionaBronwen wants to merge 3 commits into
fionabronwen/graphql-statemap-to-decoratorsfrom
fionabronwen/graphql-alloy-foundation-v2

Conversation

@FionaBronwen
Copy link
Copy Markdown

@FionaBronwen FionaBronwen commented Apr 12, 2026

Summary

This PR sets up the Alloy JSX foundation for the component-based GraphQL emitter! This PR introduces the build config, context system, and first set of components that will be used to construct the GraphQL schema in subsequent PRs.

  • Add build/config for Alloy JSX: @alloy-js/core, @alloy-js/graphql dependencies, JSX transpilation in tsconfig and vitest
  • Introduce GraphQLSchemaContext(Alloy named context) with ClassifiedTypes, and ScalarVariant interfaces for schema-wide state
  • Add field components: Field, OperationField, and GraphQLTypeExpression for rendering model properties and operations as GraphQL SDL
  • Add getGraphQLBuiltinName() to scalar-mappings for identity-based built-in scalar resolution

Test plan

  • Field components will be tested end-to-end in the next PR when the Alloy emitter is wired up

@FionaBronwen FionaBronwen changed the base branch from fionabronwen/graphql-nullable-tracking to feature/graphql April 14, 2026 16:12
@FionaBronwen FionaBronwen force-pushed the fionabronwen/graphql-alloy-foundation-v2 branch 8 times, most recently from 8f1da87 to 8b51ca4 Compare April 14, 2026 21:04
@FionaBronwen FionaBronwen marked this pull request as ready for review April 14, 2026 21:14
@FionaBronwen FionaBronwen changed the base branch from feature/graphql to fionabronwen/graphql-statemap-to-decorators April 21, 2026 16:00
@FionaBronwen FionaBronwen force-pushed the fionabronwen/graphql-alloy-foundation-v2 branch from 8b51ca4 to 8f411e1 Compare April 21, 2026 16:24
Introduce the foundation for the component-based GraphQL emitter:

- Build/config: Add @alloy-js/core, @alloy-js/graphql dependencies,
  configure JSX transpilation (tsconfig, vitest)
- Context system: GraphQLSchemaContext with ClassifiedTypes,
  ModelVariants, and ScalarVariant interfaces
- Field components: Field, OperationField, and GraphQLTypeExpression
  for rendering model properties and operations as GraphQL SDL
- Type resolution: GraphQLTypeExpression handles scalars, models,
  enums, unions, arrays, and nullability using an isInput prop to
  distinguish input vs output context
- Scalar mappings: Add getGraphQLBuiltinName() for built-in scalar
  identity checks
@FionaBronwen FionaBronwen force-pushed the fionabronwen/graphql-alloy-foundation-v2 branch from 8f411e1 to 5f26c25 Compare April 28, 2026 15:28
The ModelVariants lookup structure was originally designed to help
components decide when to append "Input" suffix to model names.
However, the mutation engine now fully handles this:
- Input models are mutated with the "Input" suffix already applied
- Property type references are rewired to point to the correct variants

This commit removes the unused ModelVariants interface and the lookup
logic from GraphQLTypeExpression, simplifying the component to just
use the model's name directly.

Also adds unionMembers to context (needed for union rendering).
Remove unused utility functions that were superseded by the mutation engine:
- getTemplatedModelName (mutation engine handles template naming)
- getSingleNameWithNamespace (never used in production)
- isArray, isRecordType, isScalarOrEnumArray, isUnionArray (use compiler's isArrayModelType)
- unwrapModel, unwrapType (never imported)
- isTrueModel (never imported)

Also removes the corresponding test for getSingleNameWithNamespace.
/**
* Classified types separated by category for schema generation
*/
export interface ClassifiedTypes {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, ClassifiedTypes looks like a projection of MutatedSchema as it merges wrapperModels into outputModels, drops voidOperations, and reshuffles a few fields. Adding a second interface is needed only if the MutatedSchema is consumed as-is by something else.

When the ariadne emitter migrates to the mutation engine, would it consume ClassifiedTypes or MutatedSchema directly? If MutatedSchema is the shared contract, should we just put that on the context?

/** Classified types for schema generation */
classifiedTypes: ClassifiedTypes;
/** Ordered member names for each union, keyed by the mutated Union */
unionMembers: Map<Union, readonly string[]>;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this being added separately to the context?

/** Ordered member names for each union, keyed by the mutated Union */
unionMembers: Map<Union, readonly string[]>;
/** Scalar specification URLs for @specifiedBy directives */
scalarSpecifications: Map<string, string>;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same question for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants