@graphql-codegen/cli@7.4.0
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
GenerateOptionsit returns frombuildGeneratesSection, 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. - by a preset, on the
Patch Changes
-
#10930
448431a
Thanks @eddeee888! - Fixoverwritebeing ignored for
preset-basedgeneratesoutputs.A
generatesentry that used a preset and setoverwrite(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
overwriteper generated file by looking the file's path up in
config.generates. That fails for a preset: itsgeneratesentry 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 apluginskey that preset entries don't have.
Both cases fell through to the globalconfig.overwrite(defaulttrue). -
Updated dependencies
[90229a5,
448431a]:- @graphql-codegen/plugin-helpers@7.3.0
@graphql-codegen/plugin-helpers@7.3.0
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
GenerateOptionsit returns frombuildGeneratesSection, 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. - by a preset, on the
Patch Changes
-
#10930
448431a
Thanks @eddeee888! - Fixoverwritebeing ignored for
preset-basedgeneratesoutputs.A
generatesentry that used a preset and setoverwrite(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
overwriteper generated file by looking the file's path up in
config.generates. That fails for a preset: itsgeneratesentry 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 apluginskey that preset entries don't have.
Both cases fell through to the globalconfig.overwrite(defaulttrue).