fix: navigate docs for input object fields

[pur3miish]

Summary

• handle ObjectField schema references in the Documentation Explorer
• preserve the owning input-object type as inputObjectType in AllTypeInfo
• resolve input fields directly from parser-provided type information instead of scanning the schema
• add regression coverage for nested mutation input fields
• declare release intent for @graphiql/react, graphql-language-service, and @graphiql/plugin-doc-explorer

Root cause

The operation editor already emits an ObjectField schema-reference event for command/control-clicks inside input object literals. The Documentation Explorer did not handle that event, and getTypeInfo retained only the input object's field map—not the owning input-object type needed to build the documentation navigation path.

Implementation

• add inputObjectType to AllTypeInfo and populate it while processing OBJECT_VALUE
• have the Documentation Explorer read the owning type from typeInfo.inputObjectType
• remove the schema parameter and reverse getTypeMap() lookup from getSchemaReference
• intentionally require the updated type-information contract without a compatibility fallback
• update the changeset with:
  • @graphiql/react: major
  • graphql-language-service: minor
  • @graphiql/plugin-doc-explorer: patch

Testing

• graphql-language-service: 277 tests passed
• @graphiql/plugin-doc-explorer: 21 tests passed
• TypeScript checks passed for both affected packages
• formatting and lint checks passed for the changed files
• Changesets release-plan validation completed

Fixes #4441

[changeset-bot]

🦋 Changeset detected

Latest commit: 31bd0a1

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 8 packages

Name	Type
@graphiql/react	Major
@graphiql/plugin-doc-explorer	Major
graphql-language-service	Minor
@graphiql/plugin-code-exporter	Major
@graphiql/plugin-explorer	Major
@graphiql/plugin-history	Major
graphiql	Patch
codemirror-graphql	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: pur3miish / name: H (695ae63)

[trevor-scheer]

Thanks for the PR!

The part that's giving me pause is threading schema into getSchemaReference so it can scan getTypeMap() for the input object that owns fieldDef. I think we're fixing this a layer too late. Could it go in the parser instead?

I'm imagining something around the OBJECT_VALUE case in getTypeInfo.ts, which already resolves the owning type and then keeps only its field map:

case RuleKinds.OBJECT_VALUE:
  const objectType = getNamedType(inputType!);
  objectFieldDefs = objectType instanceof GraphQLInputObjectType
    ? objectType.getFields()
    : null;

If we held onto objectType as well (a new field on AllTypeInfo?), the doc explorer could read it directly from typeInfo and the schema param disappears, + some other cleanup.

Let me know what you think!

[pur3miish]

Let me know what you think!

That makes sense and avoids the reverse schema lookup. One concern is that AllTypeInfo is exported from graphql-language-service, while the doc explorer accepts older @graphiql/react versions that won’t populate the new field. Would you prefer that I make inputObjectType optional and retain a compatibility fallback, or update the relevant package versions/peer range as part of this PR?

[trevor-scheer]

@pur3miish good observation. I'd be happy with the latter (no back-compat with proper versioning bumps). I'm pretty sure this just means adding a major entry to your changeset for @graphiql/react (and the doc explorer should automatically receive a patch bump for it...I can confirm it's correct before we cut the release).

So just make sure that entry is added to the changeset as well and I'll make sure the versioning is correct before release. Thanks!

I believe this changesets PR is relevant to our scenario.

[pur3miish]

@trevor-scheer Thanks for the guidance! I’ve updated the PR based on your recommendation:

• added inputObjectType to AllTypeInfo and populated it in getTypeInfo
• updated the Documentation Explorer to read the owning input-object type directly from typeInfo
• removed the schema-wide reverse lookup and compatibility fallback
• added parser and Documentation Explorer regression coverage
• updated the changeset with a major bump for @graphiql/react, a minor bump for graphql-language-service, and a patch bump for @graphiql/plugin-doc-explorer

The affected tests, type checks, formatting, and lint checks pass.

After updating the branch, the Changesets bot currently calculates major bumps for the Documentation Explorer and the other @graphiql/react peer dependents. Since you offered to confirm the versioning before release, could you take a look and let me know whether any further changes are needed? Thanks!

[pur3miish]

Hi @trevor-scheer — friendly follow-up. The parser-level change and requested @graphiql/react major changeset are now included, all CI checks pass, and the PR is mergeable. The only remaining question appears to be the Changesets propagation to peer dependents. Could you confirm whether the current versioning is acceptable and, if everything looks good, review/merge the PR? Thanks!

[trevor-scheer]

Hey @pur3miish, thank you for your patience. I'm solo parenting for the week and pretty preoccupied, I'll try to get to this as soon as I'm able to but it probably won't be until next week.