Include full code-generation configuration in // header for long-running projects
Context (Input, Language)
Input Format:
JSON
Output Language:
C# (System.Text.Json, Newtonsoft.Json, etc.)
Description
In long‑running projects, generated model code often outlives the original context in which it was created. APIs evolve, breaking changes are introduced, and projects often transition from one JSON framework to another (e.g. Newtonsoft.Json → System.Text.Json).
When reviewing or regenerating code months or years later, it is currently impossible to tell:
which JSON framework was used
which generation options were selected
whether changes in behavior are caused by API changes or different generator settings
This lack of visibility makes maintenance, refactoring, and framework migration unnecessarily error‑prone.
Having the exact generation parameters embedded directly in the generated source file would allow developers to understand at a glance how and why the code was generated.
Current Behaviour / Output
Generated files only include a generic auto-generated marker and usage hint, for example:
// <auto-generated />
//
// To parse this JSON data, add NuGet 'System.Text.Json' then do:
//
// using Importer.Auvik.Models;
//
// var devicesResponse = DevicesResponse.FromJson(jsonString);
Once this code is committed:
The original Quicktype UI settings are lost
There is no way to verify whether the code matches current generation defaults
During API changes or framework migrations, differences are hard to diagnose
Proposed Behaviour / Output
Extend the // header to include a clear, structured summary of all code-generation parameters that were used.
This enables immediate understanding of:
serialization framework
collection types
namespace
optionality rules
virtual property generation
strictness settings
Example:
// <auto-generated />
//
// Quicktype Generation Settings:
// Input format: JSON
// Target language: C#
// JSON framework: System.Text.Json
// Collection type: List<T>
// Generated namespace: Importer.Auvik.Models
// Output features: Complete
// Generate virtual properties: True
// Fail if required properties are missing: False
// Keep original JSON field names: False
// Make all properties optional: True
//
// To parse this JSON data, add NuGet 'System.Text.Json' then do:
Solution
Add a feature that automatically emits all active code‑generation parameters into the generated file header:
Included by default (or optionally configurable)
Human‑readable and stable for source control diffs
Ordered consistently (preferably matching the UI or CLI option order)
Target‑language comment style aware
This turns generated code into self‑describing artifacts, suitable for long‑term maintenance.
Alternatives
External documentation
Maintaining separate documentation for generation settings is fragile and often goes out of sync with the actual generated code.
Relying on defaults
Defaults can and do change between versions, making assumptions unsafe in long‑running projects.
Regenerating and comparing output
This is slow, unreliable, and does not clearly explain why differences exist.
None of these alternatives provide the immediate clarity needed during breaking API changes or serialization framework migrations.
Context
This feature is especially valuable in:
Multi‑year projects
Teams with multiple contributors
API client regeneration workflows
Codebases that migrate between JSON frameworks
Reviewing regressions after API breaking changes
Being able to see the generation configuration in a blink of an eye directly in the source file significantly improves confidence, maintainability, and debugging speed.
Include full code-generation configuration in // header for long-running projects
Context (Input, Language)
Input Format:
JSON
Output Language:
C# (System.Text.Json, Newtonsoft.Json, etc.)
Description
In long‑running projects, generated model code often outlives the original context in which it was created. APIs evolve, breaking changes are introduced, and projects often transition from one JSON framework to another (e.g. Newtonsoft.Json → System.Text.Json).
When reviewing or regenerating code months or years later, it is currently impossible to tell:
which JSON framework was used
which generation options were selected
whether changes in behavior are caused by API changes or different generator settings
This lack of visibility makes maintenance, refactoring, and framework migration unnecessarily error‑prone.
Having the exact generation parameters embedded directly in the generated source file would allow developers to understand at a glance how and why the code was generated.
Current Behaviour / Output
Generated files only include a generic auto-generated marker and usage hint, for example:
Once this code is committed:
The original Quicktype UI settings are lost
There is no way to verify whether the code matches current generation defaults
During API changes or framework migrations, differences are hard to diagnose
Proposed Behaviour / Output
Extend the // header to include a clear, structured summary of all code-generation parameters that were used.
This enables immediate understanding of:
serialization framework
collection types
namespace
optionality rules
virtual property generation
strictness settings
Example:
Solution
Add a feature that automatically emits all active code‑generation parameters into the generated file header:
Included by default (or optionally configurable)
Human‑readable and stable for source control diffs
Ordered consistently (preferably matching the UI or CLI option order)
Target‑language comment style aware
This turns generated code into self‑describing artifacts, suitable for long‑term maintenance.
Alternatives
External documentation
Maintaining separate documentation for generation settings is fragile and often goes out of sync with the actual generated code.
Relying on defaults
Defaults can and do change between versions, making assumptions unsafe in long‑running projects.
Regenerating and comparing output
This is slow, unreliable, and does not clearly explain why differences exist.
None of these alternatives provide the immediate clarity needed during breaking API changes or serialization framework migrations.
Context
This feature is especially valuable in:
Multi‑year projects
Teams with multiple contributors
API client regeneration workflows
Codebases that migrate between JSON frameworks
Reviewing regressions after API breaking changes
Being able to see the generation configuration in a blink of an eye directly in the source file significantly improves confidence, maintainability, and debugging speed.