chore(deps): update graphqlcodegenerator monorepo

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@graphql-codegen/cli (source)	7.3.1 → 7.4.0
@graphql-codegen/plugin-helpers (source)	7.2.1 → 7.3.0

---

Release Notes

dotansimha/graphql-code-generator (@​graphql-codegen/cli)

v7.4.0

Compare Source

Minor Changes

• #​10928
  90229a5
  Thanks @​eddeee888! - Add
  contentComparison?: 'cache-first' | 'disk' to control disk-vs-cache write comparison in watch
  mode.

  In watch mode the CLI caches the hash of the content it last wrote per file and compares new
  output against that cached hash to skip redundant writes. This assumes generated output is a pure
  function of the codegen inputs. An output whose content depends on the file's existing content
  (e.g. a preset that reads the file and rewrites part of it) breaks that assumption: if the file is
  changed on disk and codegen regenerates content identical to a previous run, the cached hash still
  matches and the write is skipped, so the on-disk change is never corrected.

  contentComparison: 'disk' opts an output into comparing the generated content against the file
  on disk instead of the in-memory record of what codegen last wrote, so the file is rewritten when
  it was changed externally. It can be set:

  • by a preset, on the GenerateOptions it returns from buildGeneratesSection, or
  • on the output config (generates[output].contentComparison) for any output, including plain
    plugin outputs without a preset.

  When both are present, the preset's value takes precedence. The default, 'cache-first', keeps
  the existing in-memory-cache behaviour for outputs that are a pure function of their inputs.

Patch Changes

• #​10930
  448431a
  Thanks @​eddeee888! - Fix overwrite being ignored for
  preset-based generates outputs.

  A generates entry that used a preset and set overwrite (e.g.
  overwrite: { removeStaleFiles: false }) had that setting silently ignored, so in watch mode its
  generated files could still be deleted as stale.

  The CLI resolved overwrite per generated file by looking the file's path up in
  config.generates. That fails for a preset: its generates entry is keyed by the preset's
  baseOutputDir, not by any generated file's path (and a preset can emit files outside that
  directory), and the lookup additionally required a plugins key that preset entries don't have.
  Both cases fell through to the global config.overwrite (default true).

• Updated dependencies
  [90229a5,
  448431a]:

  • @​graphql-codegen/plugin-helpers@7.3.0

dotansimha/graphql-code-generator (@​graphql-codegen/plugin-helpers)

v7.3.0

Compare Source

Minor Changes

• #​10928
  90229a5
  Thanks @​eddeee888! - Add
  contentComparison?: 'cache-first' | 'disk' to control disk-vs-cache write comparison in watch
  mode.

  In watch mode the CLI caches the hash of the content it last wrote per file and compares new
  output against that cached hash to skip redundant writes. This assumes generated output is a pure
  function of the codegen inputs. An output whose content depends on the file's existing content
  (e.g. a preset that reads the file and rewrites part of it) breaks that assumption: if the file is
  changed on disk and codegen regenerates content identical to a previous run, the cached hash still
  matches and the write is skipped, so the on-disk change is never corrected.

  contentComparison: 'disk' opts an output into comparing the generated content against the file
  on disk instead of the in-memory record of what codegen last wrote, so the file is rewritten when
  it was changed externally. It can be set:

  • by a preset, on the GenerateOptions it returns from buildGeneratesSection, or
  • on the output config (generates[output].contentComparison) for any output, including plain
    plugin outputs without a preset.

  When both are present, the preset's value takes precedence. The default, 'cache-first', keeps
  the existing in-memory-cache behaviour for outputs that are a pure function of their inputs.

Patch Changes

• #​10930
  448431a
  Thanks @​eddeee888! - Fix overwrite being ignored for
  preset-based generates outputs.

  A generates entry that used a preset and set overwrite (e.g.
  overwrite: { removeStaleFiles: false }) had that setting silently ignored, so in watch mode its
  generated files could still be deleted as stale.

  The CLI resolved overwrite per generated file by looking the file's path up in
  config.generates. That fails for a preset: its generates entry is keyed by the preset's
  baseOutputDir, not by any generated file's path (and a preset can emit files outside that
  directory), and the lookup additionally required a plugins key that preset entries don't have.
  Both cases fell through to the global config.overwrite (default true).

---

Configuration

📅 Schedule: (in timezone Asia/Tokyo)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: pnpm-lock.yaml

? Verifying lockfile against supply-chain policies (882 entries)...
[WARN] Request took 10205ms: https://registry.npmjs.org/@graphql-codegen%2Fcli
✗ Lockfile failed supply-chain policy check (882 entries in 11.4s)
[ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION] 1 lockfile entries failed verification:
  eslint@10.10.0 was published at 2026-09-04T14:34:21.799Z, within the minimumReleaseAge cutoff (2026-09-04T09:09:13.910Z)

The lockfile contains entries that the active policies reject. This can mean the lockfile is stale, or that someone committed a lockfile that bypassed the policy locally — inspect recent changes to pnpm-lock.yaml before trusting it. If the changes look expected, run "pnpm clean --lockfile" and then "pnpm install" to rebuild from a fresh resolution. Alternatively, relax the policy that flagged them.