Swagger Codegen vs. OpenAPI Generator: Consistent polymorphic model generation in CI/CD

Direct answer

There is no single CLI flag that forces one consistent polymorphism strategy across Java, TypeScript, and Go. The only reliable way to lock output is to treat the generator and its templates as pinned build dependencies, enforce strict discriminator definitions in the spec, and fail CI when generated code drifts from a committed baseline.

Confirmed behavior vs. likely template behavior

Confirmed: Swagger Codegen is legacy; OpenAPI Generator is the active fork. Polymorphic mapping for oneOf and anyOf is implemented independently in each language's Mustache templates. There is no universal cross-language strategy option in stable releases, and a minor template change can alter class hierarchies without any change to command-line flags.

Likely but version-dependent: Java generators tend to expose discriminator-lookup options; TypeScript generators tend toward union types with optional discriminator fields; Go generators often emit generic structures because native sum types are limited. These behaviors vary by release and library, so verify them against your pinned version rather than assuming parity.

Steps to enforce stability in CI/CD

1. Pin the generator and templates. Use an exact release tag and a specific template commit. Vendoring templates means a template change requires an explicit commit and review.
2. Enforce discriminator discipline in the spec. Every oneOf/anyOf parent should declare discriminator.propertyName and an explicit mapping for each child. Missing mappings cause fallback to Object or any in several languages.
3. Commit generated code or diff it. After generation, compare file hashes against a known-good baseline. A simple gate is git diff --exit-code generated/.
4. Run per-language round-trip tests. Serialize and deserialize each polymorphic variant to confirm runtime discrimination works with the pinned output.

# Illustrative CI snippet (adapt to your toolchain)
docker run --rm -v "${PWD}:/local" \
  openapitools/openapi-generator-cli:<exact-tag> generate \
  -i /local/openapi.yaml \
  -g <language> \
  -t /local/templates/<language> \
  -o /local/generated/<language>

git add generated/
git diff --cached --exit-code || exit 1

Versions, template forks, and CLI options

No specific OpenAPI Generator version is universally "most reliable" for polymorphism across all three languages; reliability comes from the pinning discipline above. Prefer the latest stable release you have already validated over the newest available. Template forks should be adopted only after reviewing diffs against upstream, because vendoring increases maintenance cost and delays upstream fixes.

There is no forthcoming CLI option to select a polymorphism strategy explicitly in stable releases today. Any such feature would be speculative until it is released and documented; treat it as unverified.

One missing diagnostic detail

One detail would change the recommendation: whether your specs already define explicit discriminator.propertyName and mapping for every subschema. If they do not, closing that spec gap matters more than any generator or template change.