[near-operation-file-preset] Fix unused interface fragment type impor…

[wassim-k]

Description

near-operation-file narrows the imports for a polymorphic fragment to the types a document actually uses (#1112,
fixed in #1113), but only for spreads that sit under a field. A spread at the top level of another fragment
definition is never analysed, so it falls back to importing every possible type of the fragment.

fragment AnimalFragment on IAnimal {
  name
}

fragment CatFragment on Cat {
  ...AnimalFragment
}

CatFragment's generated file imports both AnimalFragment_Cat and AnimalFragment_Dog and uses only the first,
so a project with "noUnusedLocals": true fails to compile — the same symptom #1112 reported, through a fragment
rather than an operation. It surfaces as soon as a second type implements the interface.

analyzeFragmentTypeUsage now also visits each FragmentDefinition, analysing its selection set against its type
condition just as it does a field's selection set against the field's type.

Related #1112

Type of change

• Bug fix (non-breaking change which fixes an issue)

Screenshots/Sandbox (if appropriate/relevant):

N/A — the inline snapshot in the new test shows the generated output.

How Has This Been Tested?

• Added #1112 - should import only interface types that are in use when spread directly in a fragment, next
  to the existing [near-opeation-file] imports to interface fragment should only include types that are used in file. #1112 test and using the same schema; a new fixture spreads AnimalFragment at the top of
  fragment CatFragment on Cat. The test fails without the change and passes with it.
• Ran the full test suite after yarn build: 1592 passed, 1 skipped.

Test Environment:

• OS: Windows 11
• @graphql-codegen/near-operation-file-preset: 5.2.2 (main at da72b1235)
• NodeJS: 24.18.1

Checklist:

• I have followed the
  CONTRIBUTING doc and the
  style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

Further comments

The change reuses the existing analyzeSelectionSetTypeContext rather than adding a separate path for fragment
definitions, so top-level spreads are narrowed by exactly the same rules as spreads under a field.

No new comments or documentation were needed: the change is a single visitor entry mirroring the existing Field
one, and the preset's documented behaviour is unchanged. It has no dependent changes.

[changeset-bot]

🦋 Changeset detected

Latest commit: c2a346e

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

This PR includes changesets to release 1 package

Name	Type
@graphql-codegen/near-operation-file-preset	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