[dinwwwh]

Requested by dinwwwh · project thread

Docs only. Adds two sentences to the datamodel-code-generator bullet in packages/downgrader/README.md.

A 3.1 type list with integer and an enum, such as Litestar's Literal["a", "b", 1] ({ type: ["integer", "string"], enum: ["a", "b", 1] }), becomes { enum: [...], anyOf: [{ type: "integer" }, { type: "string" }] } in 3.0. datamodel-code-generator 0.86.0 writes class G(IntEnum) for that, so importing the generated models raises ValueError: invalid literal for int() with base 10: 'a'. From the 3.1 input it writes one Enum, and the import works. I reproduced both results on current main.

Only an integer branch triggers it, so Valibot's mixed picklist (number) is fine. The per-type oneOf and bare enum shapes were already ruled out because they make NSwag, Kiota and oapi-codegen worse. An enum beside a type list that holds integer appears in only 2 of about 11,750 corpus documents. So it gets a README note, not a change to the converter.

---

Generated by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed]

Merging this PR will not alter performance

✅ 21 untouched benchmarks

---

_{Comparing claude/project-thread-mmrczx (cfa65ab) with main (46cabee)}

[pullfrog]

✅ No new issues found.

Reviewed changes

Docs-only change to packages/downgrader/README.md (one line appended to the datamodel-code-generator bullet). I verified the claim end-to-end rather than taking it on trust.

• datamodel-code-generator IntEnum note — records that a 3.1 type list holding integer beside an enum, such as Litestar's Literal["a", 1], downgrades to an enum beside an anyOf, which datamodel-code-generator 0.86.0 reads as an IntEnum whose import then raises ValueError: invalid literal for int() with base 10: 'a'.

Verification: a downgradeSchemaV31ToV30 probe produced exactly { enum: ["a", 1], anyOf: [{ type: "integer" }, { type: "string" }] }; datamodel-code-generator==0.86.0 emitted class G1(IntEnum) and failed to import for that shape, emitted a single Enum with a clean import for the 3.1 input, and emitted Enum (not IntEnum) when the branch is number — so the note's integer specificity is correct. uncheck packages/downgrader/README.md passes (oxlint + oxfmt).

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash (free via Pullfrog for OSS) ｜ 𝕏}