Proposal: improve fragment-aware linting through three focused PRs

[ikusakov2]

I’d like to upstream a series of changes that make GraphQL ESLint work better with reusable fragments, including fragments shared between packages in a monorepo.

The proposed split is:

1. Fix existing processor and cache issues.
   PR #2977 (https://github.com/graphql-hive/graphql-eslint/pull/2977) clears stale processor offsets between editor buffers and prevents obsolete sibling-document snapshots from being retained indefinitely. These fixes are independent of the new features.
2. Add operationsOnly: true to require-selections rule.
   PR #2980 implements this option; it is stacked on PR Fix stale processor offsets and sibling-cache retention #2977.
   This rule-specific option would check required fields in the completed operation, allowing individual fragments to provide partial selections. For example, the rule requires id to be selected:

query {
  business {
    id
    ...BusinessDetails
  }
}

fragment BusinessDetails on Business {
  name
}

The operation selects the required field, but the current rule also checks BusinessDetails independently and reports missing ID. Operation-only checking would allow this composition. It would also merge matching response fields across fragments and correctly isolate interface/union branches.

Nested fragment resolution already exists; the motivation is allowing requirements to be satisfied by the combined operation. The option would default to false, preserve existing behavior when omitted, and have no effect on other rules.

3. Add context-aware document loading and an optional @graphql-tool/external-fragment-loader adapter.

In a monorepo, an operation may consume fragments supplied by other packages. We need to resolve the relevant documents for the consumer package without scanning every workspace document or maintaining a separate GraphQL Config project for each package.

The proposal adds a generic parserOptions.documentLoader(context) hook, with an optional adapter for @graphql-tools/external-fragment-loader handling package-based discovery. Existing document loading remains the default. The adapter and operationsOnly are independently configurable.

I’d appreciate feedback on this proposal, particularly the operation-only semantics and whether the external-fragment adapter can be added in this repository as an optional integration.