* [kotlin] Add companionObject option to generate companion objects in data classes
Add a new boolean CLI option `companionObject` (default: false) that generates
an empty `companion object { }` on all data class models, enabling users to add
companion extensions from outside the generated code.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* [kotlin-spring] Add companionObject option to generate companion objects in data classes
Extend the same companionObject option to the kotlin-spring server generator,
enabling companion extensions on generated Spring model classes.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* update spec, add tests
---------
Co-authored-by: Jeffrey Blayney <jeffrey.blayney@missionlane.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* feat: add support for Jackson 3 and Spring Boot 4 in Java resttemplate client generation
* chore: remove deprecated resttemplate-springBoot4 paths from YAML configuration
* feat: add serialization library support for Jackson 3 in Java client
* chore: initialize project structure and add initial files
* feat: update library template for Spring RestTemplate to support Jackson 3
* chore: add paths for resttemplate-springBoot4 in YAML configuration
* chore: remove unused test files from the project
* chore: add libs.versions.toml and update FILES for new test files
* chore: remove unused test files from the project
* Fix to_dict method
* Fix union type hint
* Use more concise code for dict generation
* Add from dict method for array of dicts
* Fix after reviewer comments
* add check for none
* Update samples
* fix(typescript-fetch): generate validationAttributes when withoutRuntimeChecks=true
Previously, setting `validationAttributes=true` had no effect when
`withoutRuntimeChecks=true` was set. This commit fixes that by adding
the validation attributes to the `modelGenericInterfaces.mustache`
template (that is used when withoutRuntimeChecks is enabled)
- Moves validationAttributes logic to a partial template and includes it
in the modelGenericInterfaces.mustache template
- modelGeneric.mustache includes the modelGenericInterfaces.mustache
partial and should work as before
* update samples
Problem
SynchronizedDictionary is a struct held as a var property on shared singleton classes (URLSessionRequestBuilderConfiguration and AlamofireRequestBuilderConfiguration). When multiple concurrent network requests mutate credentialStore or managerStore from different
threads, Swift's memory exclusivity rules treat each subscript mutation as a modifying access to the entire struct — causing a real ThreadSanitizer "Swift access race".
Changes
struct → class (SynchronizedDictionary.mustache + 13 sample files)
Changing SynchronizedDictionary from a value type to a reference type makes mutations go through pointer indirection. Concurrent subscript writes now only touch the object's internal state (already protected by NSRecursiveLock), rather than triggering a modifying
access on the owning class's stored property.
var → let (URLSessionImplementations.mustache + 11 sample files, AlamofireImplementations.mustache + 2 sample files)
Since SynchronizedDictionary is now a class, the properties credentialStore and managerStore only need to hold a stable reference — they never get reassigned. Declaring them as let makes this intent explicit and prevents any residual exclusivity issues on the property
itself.
* Add support for `Optional<T>` in Dart generator (both dart and dart-dio) to distinguish absent, null, and present states
* Add useOptional and patchOnly options to the Dart client configurations thing for testing (setting both options to "true" for both types)
* Add documentation for useOptional and patchOnly options
* Tune the dart mustache (pluss class mustache) to get rid of the extra whitespace
* More tuning of the dart mustache files to adjust amount of whitespace - match previously generated setup
* Tune dart mustache templates to fix whitespace stuff by tips from wing328
* Fix the logic gap where useOptional=true without patchOnly=true appears to do nothing
* Rename getString() to extractModelNameFromBodyParam()
* Add behavioral tests
* useOptional flag wrapping non-required properties
* patchOnly mode PATCH schema detection
* patchOnly=true auto-enabling useOptional
* Parameter unwrapping behavior
* Fix inconsistency (my own) in native_class.mustache
* Remove "dead code" (because of timing). postProcessModels has already executed before postProcessOperationsWithModels.
And then we don't even need the extractModelNameFromBodyParam method...
* Fix Optional<T> to properly distinguish between absend and null
Had issues in dio
* Regenerate Dart samples
* Fix extra blank lines in dart-dio json_serializable template output
* test: add test case for `ExclusiveMinMax Test`
(#22943)
* feat: Compatibility with exclusiveMinimum in OpenAPI 3.0.0 vs. 3.1.0
(#22943)
---------
Co-authored-by: 葉宗原 TsungYuan Yeh <tsungyuan.yeh@tpisoftware.com>
* fix(kotlin): use sealed interface for non-discriminator oneOf/anyOf in kotlinx_serialization
* add sample and CI config for non-discriminator oneOf/anyOf with kotlinx_serialization
* replace petstore with focused spec for non-discriminator oneOf/anyOf sample
* add CI path filter for kotlin-oneOf-anyOf-kotlinx-serialization sample
* add x-duplicated-data-type guard to kotlinx_serialization oneOf/anyOf templates
The Gson path already uses {{^vendorExtensions.x-duplicated-data-type}} to skip
duplicate data types, but the new kotlinx_serialization path was missing this
guard. Without it, duplicate value class names would be generated if multiple
schemas resolve to the same Kotlin dataType, causing compilation errors.
* remove invalid path pattern from push.branches in CI config
push.branches filters by branch name, not file paths. The sample directory
pattern added here had no effect. The pull_request.paths filter remains and
correctly triggers CI for this sample.
* update generateOneOfAnyOfWrappers docs to include kotlinx_serialization support
* test: add failing test for missing @deprecated on array properties in OAS 3.1
The typescript-axios generator drops the @deprecated JSDoc annotation
for array-type properties when processing OpenAPI 3.1 specs. This test
reproduces the issue by asserting that deprecated scalar, array-of-primitives,
and array-of-refs properties all receive the annotation.
* fix: preserve deprecated, readOnly, writeOnly when normalizing OAS 3.1 array schemas
The OpenAPINormalizer.processNormalize31Spec method converts OAS 3.1
JsonSchema array types into legacy ArraySchema objects, but was not
copying the deprecated, readOnly, or writeOnly flags during conversion.
This caused @deprecated annotations to be silently dropped for array-type
properties in all generators when processing OAS 3.1 specs.
* [OCaml] Fix bugs around enum parsing
Problem: The OCaml client generator threw IllegalArgumentException: Unreferenced enum when encountering enums inside composed schemas
(anyOf/allOf/oneOf).
Root Causes:
1. The enum collection logic didn't traverse into composed schemas
2. The enum hashing used order-dependent string concatenation, causing lookups to fail when enum values appeared in different orders
3. Enums directly within composed schema branches (not in properties) weren't collected
Solution:
1. Added composed schema support:
- New `collectEnumSchemasFromComposed()` method handles `anyOf/allOf/oneOf`
- New `collectEnumSchemasFromList()` method recursively processes composed schema branches
- Enums directly in composed schemas (not just in properties) are now collected
2. Refactored enum hashing to use Set:
- Changed from comma-joined strings to `TreeSet<String>` for order-independent, collision-free hashing
- Handles edge cases like empty string enums `""`
3. Added test case:
- Tests enums in nested composed schemas
- Tests enum with empty string value in anyOf
* OCaml: Add support for direct recursive types
* OCaml: Fix enums in anyOf
* OCaml: fix recursive types
* Fix recursion tests
* Fix recursive types, improve tests
* [OCaml] Improve title of generated README.md
* fix: support numeric exclusiveMinimum/exclusiveMaximum in OpenAPI 3.1 (#22943)
* preserving the stricter constraint when both bounds are defined. (#22943)
