Reviewing files that changed from the base of the PR and between c3e159c and 1457063.

• docs/cli-reference/model-customization.md
• docs/cli-reference/template-customization.md
• src/datamodel_code_generator/__init__.py
• tests/main/test_main_general.py
• tests/main/test_public_api_signature_baseline.py

docs/cli-reference/model-customization.md (1)

1371-1379: Literal typing for Api.version example looks consistent and precise

Importing Literal and tightening Api.version to Literal['v1'] alongside Field('v1', const=True, ...) accurately reflects the const constraint and aligns this Pydantic v1 example with the other literal-based examples in the section.

docs/cli-reference/template-customization.md (1)

76-77: Tightened MapState literals and added import are well-aligned with the schema

Adding Literal to the typing imports and switching map_view_mode, map_split_mode, and is_split to Literal[...] types (while keeping the existing Field(..., const=True, alias=...)) matches the JSON Schema const constraints and makes the example’s static types more precise without changing the intended semantics.

Also applies to: 2562-2564, 2574-2578

tests/main/test_public_api_signature_baseline.py (1)

605-612: Passing output via GenerateConfig makes the comparison test more representative

Moving output=output_config into the GenerateConfig(...) call and invoking generate(input_=schema, config=config) ensures this test now exercises the pure “config‑only” path versus the pure “kwargs‑only” path, without mixing shared options across both. That more accurately validates that config‑driven and kwargs‑driven generation remain behaviorally equivalent.

tests/main/test_main_general.py (2)

1972-1995: LGTM!

The test correctly validates that GenerateConfig now accepts an output parameter and uses it properly. The test structure follows existing patterns.

---

1997-2014: LGTM!

The new test properly validates the mutual exclusivity constraint between config and keyword arguments. The test:

• Creates a config object without an output path
• Attempts to pass output as a keyword argument alongside the config
• Correctly expects a ValueError with the appropriate message

This ensures the API contract is enforced.

src/datamodel_code_generator/__init__.py (4)

477-479: LGTM!

The mutual exclusivity check is correctly implemented. Raising ValueError when both config and **options are provided ensures a clear API contract and prevents ambiguous configurations.

---

635-640: LGTM!

Using DataclassArguments() to create an empty typed dict is correct. The subsequent conditional logic properly populates frozen and kw_only keys based on the config flags.

---

1080-1107: LGTM!

The __all__ exports are appropriately expanded to include newly exposed public API elements like DEFAULT_FORMATTERS, DEFAULT_SHARED_MODULE_NAME, AllOfMergeMode, CollapseRootModelsNameStrategy, FieldTypeCollisionStrategy, GraphQLScope, OpenAPIScope, PythonVersionMin, and ReuseScope.

---

450-454: The noqa directives on line 450 are technically unused and can be safely removed.

The rules PLR0912, PLR0914, and PLR0915 are explicitly listed in lint.ignore in pyproject.toml, so Ruff will not check these violations regardless of the noqa directives. Since the rules are disabled at the configuration level, the directives have no effect. They can be removed without consequence, though keeping them for documentation purposes is also acceptable given the function's 603-line span.

Reviewing files that changed from the base of the PR and between 1457063 and 356d859.

• src/datamodel_code_generator/__init__.py
• src/datamodel_code_generator/_types/generate_config_dict.py
• src/datamodel_code_generator/_types/parser_config_dict.py
• src/datamodel_code_generator/config.py
• tests/main/test_main_general.py
• tests/main/test_public_api_signature_baseline.py

• GitHub Check: py312-isort5 on Ubuntu
• GitHub Check: py312-pydantic1 on Ubuntu
• GitHub Check: 3.12 on Windows
• GitHub Check: 3.14 on macOS
• GitHub Check: 3.12 on macOS
• GitHub Check: 3.11 on Ubuntu
• GitHub Check: py312-black24 on Ubuntu
• GitHub Check: py312-isort7 on Ubuntu
• GitHub Check: py312-black22 on Ubuntu
• GitHub Check: py312-isort6 on Ubuntu
• GitHub Check: 3.12 on Ubuntu
• GitHub Check: 3.13 on Windows
• GitHub Check: 3.10 on macOS
• GitHub Check: 3.11 on Windows
• GitHub Check: 3.13 on Ubuntu
• GitHub Check: 3.11 on macOS
• GitHub Check: 3.10 on Windows
• GitHub Check: 3.14 on Windows
• GitHub Check: Analyze (python)
• GitHub Check: benchmarks

src/datamodel_code_generator/_types/parser_config_dict.py (1)

49-49: LGTM! Type expansion for aliases field.

The change from Mapping[str, str] to Mapping[str, str | list[str]] allows each alias to map to either a single string or a list of strings, providing greater flexibility. This is consistent with parallel changes in GenerateConfigDict and the config models.

src/datamodel_code_generator/_types/generate_config_dict.py (1)

55-55: LGTM! Consistent type expansion.

The aliases field type expansion matches the change in ParserConfigDict, maintaining consistency across the configuration type definitions.

src/datamodel_code_generator/config.py (2)

88-88: LGTM! Consistent type expansion in GenerateConfig.

The aliases field type matches the corresponding TypedDict definition, maintaining type consistency across the configuration models.

---

223-223: LGTM! Consistent type expansion in ParserConfig.

The change aligns with the GenerateConfig model and the TypedDict definitions, ensuring uniform alias handling across parsers.

tests/main/test_public_api_signature_baseline.py (2)

452-469: LGTM! Test correctly validates new config-driven signature.

The test now verifies that GenerateConfigDict keys match the baseline function's keyword-only arguments (excluding 'config'), which appropriately validates backward compatibility for the new **options: Unpack[GenerateConfigDict] signature.

---

659-666: LGTM! Test correctly demonstrates config-driven usage.

The test now passes output via the GenerateConfig object rather than as a keyword argument to generate(), correctly demonstrating the new config-driven API pattern while ensuring functional parity with the kwargs path.

tests/main/test_main_general.py (2)

979-995: LGTM! Test updated for config-driven usage.

The test now correctly passes output through the GenerateConfig object, demonstrating the intended config-driven pattern for the new API.

---

998-1014: LGTM! Test correctly validates mutual exclusivity.

The test appropriately verifies that passing both a config object and keyword arguments raises a ValueError with the expected message, ensuring proper enforcement of the mutual exclusivity constraint.

src/datamodel_code_generator/__init__.py (5)

12-13: LGTM! Import changes support config-driven API.

The new imports (defaultdict, Mapping, Unpack, GenerateConfigDict) are all necessary for the refactored signature and config handling logic.

Also applies to: 28-28, 63-63

---

450-494: LGTM! Clean migration to config-driven API.

The signature refactoring successfully:

• Simplifies the API by accepting either a GenerateConfig object or individual options via **options: Unpack[GenerateConfigDict]
• Enforces mutual exclusivity between config and **options with a clear error message
• Properly handles Pydantic v1 vs v2 differences (model_validate vs init, model_rebuild vs update_forward_refs)

The approach maintains backward compatibility through the **options path while enabling the cleaner config object pattern.

---

495-616: LGTM! Systematic config extraction maintains compatibility.

The extraction of all config values to local variables ensures the rest of the function continues to work unchanged. The special handling for extra_template_data (converting to defaultdict when provided) is appropriate given the function's internal expectations.

---

636-636: LGTM! Proper initialization of DataclassArguments.

The explicit initialization of DataclassArguments() ensures the variable is properly typed and prevents potential issues when conditionally adding keys.

---

1080-1111: LGTM! Expanded public exports for convenience.

The additions to __all__ expose commonly used constants and enums (DEFAULT_FORMATTERS, DEFAULT_SHARED_MODULE_NAME, AllOfMergeMode, CollapseRootModelsNameStrategy, FieldTypeCollisionStrategy, GraphQLScope, OpenAPIScope, PythonVersionMin, ReuseScope), improving the public API surface without breaking changes.

Reviewing files that changed from the base of the PR and between 356d859 and 21d6248.

• src/datamodel_code_generator/__init__.py
• src/datamodel_code_generator/_types/generate_config_dict.py
• src/datamodel_code_generator/_types/parser_config_dict.py
• src/datamodel_code_generator/config.py
• src/datamodel_code_generator/parser/base.py
• src/datamodel_code_generator/parser/graphql.py
• src/datamodel_code_generator/parser/jsonschema.py
• src/datamodel_code_generator/parser/openapi.py
• src/datamodel_code_generator/reference.py
• tests/main/test_public_api_signature_baseline.py

• src/datamodel_code_generator/config.py

• GitHub Check: 3.10 on Ubuntu
• GitHub Check: py312-isort6 on Ubuntu
• GitHub Check: 3.11 on Ubuntu
• GitHub Check: 3.11 on macOS
• GitHub Check: py312-black23 on Ubuntu
• GitHub Check: 3.12 on Windows
• GitHub Check: 3.11 on Windows
• GitHub Check: 3.10 on Windows
• GitHub Check: 3.14 on Windows
• GitHub Check: 3.13 on Ubuntu
• GitHub Check: 3.13 on Windows
• GitHub Check: Analyze (python)
• GitHub Check: benchmarks

src/datamodel_code_generator/_types/generate_config_dict.py (1)

56-56: LGTM! Consistent with ParserConfigDict changes.

The aliases type widening matches the corresponding change in ParserConfigDict, maintaining consistency across configuration types. This enables Pydantic v2 AliasChoices support at the generation level.

src/datamodel_code_generator/parser/jsonschema.py (1)

661-661: LGTM! Implementation already supports list aliases.

The parameter type widening aligns with the TypedDict changes and is well-supported by the existing implementation. Multiple locations in the codebase (lines 1227-1233, 2367-2372, 2548-2565) already handle both string and list aliases correctly using isinstance checks:

if isinstance(alias, list):
    validation_aliases = alias
else:
    single_alias = alias

This backward-compatible change enables Pydantic v2 AliasChoices functionality.

src/datamodel_code_generator/_types/parser_config_dict.py (1)

50-50: Type widening for multi-alias support aligns with Pydantic v2 integration.

The change from Mapping[str, str] to Mapping[str, str | list[str]] correctly widens the type to support multiple aliases per field, consistent with Pydantic v2's AliasChoices feature. This is a backward-compatible change since existing Mapping[str, str] values remain valid. The type definition itself is sound and properly reflects the intended schema.

src/datamodel_code_generator/parser/base.py (1)

690-711: Alias type widening in Parser.__init__ is consistent

Changing aliases to Mapping[str, str | list[str]] | None matches ModelResolver / FieldNameResolver expectations and cleanly enables multi-alias (AliasChoices) without affecting existing string-only callers.

src/datamodel_code_generator/reference.py (1)

523-575: ModelResolver aliases type aligned with FieldNameResolver

The aliases: Mapping[str, str | list[str]] | None parameter is correctly propagated into FieldNameResolver, keeping alias semantics consistent while allowing multiple aliases per field.

src/datamodel_code_generator/parser/graphql.py (1)

103-136: GraphQLParser aliases signature matches core parser API

aliases: Mapping[str, str | list[str]] | None is correctly widened and forwarded to Parser.__init__, keeping the GraphQL parser in sync with the new multi-alias support.

src/datamodel_code_generator/parser/openapi.py (1)

185-216: OpenAPIParser aliases parameter updated appropriately

The aliases kwarg type is widened to Mapping[str, str | list[str]] | None and passed through to the base parser, matching the rest of the alias-handling stack.

tests/main/test_public_api_signature_baseline.py (3)

55-75: Baseline aliases parameters updated to multi-alias type

The _baseline_generate and _BaselineParser.__init__ signatures now use aliases: Mapping[str, str | list[str]] | None, matching the real API and GenerateConfigDict / ParserConfigDict types so the baseline tests accurately track the public surface.

Also applies to: 184-205

---

455-472: Signature baseline now directly validated against GenerateConfigDict

test_generate_signature_matches_baseline comparing baseline kw-only args (excluding config) to GenerateConfigDict.__annotations__ is a nice tightening: it ensures the Unpack-based generate() signature stays aligned with the TypedDict keys and gives a clear diff when something drifts.

---

634-674: Config vs kwargs output equivalence test is precise and robust

test_generate_with_config_produces_same_result_as_kwargs now writes to two explicit files (output_kwargs.py and output_config.py) and compares their contents, with GenerateConfig(output=output_config, ...) mirroring the kwargs path. This is a good, minimal check that the new config-driven path is behaviorally identical to the kwargs path.

src/datamodel_code_generator/__init__.py (4)

1083-1115: LGTM! Public API expansion is correctly implemented.

The newly exported constants and types are all properly imported from their respective modules and align with the PR objective to expand the public API surface. This makes these types more accessible for users who want to configure generation programmatically.

---

482-494: Performance: Forward reference resolution executes on every call; remove unused noqa directives.

Two concerns:

1. Performance issue: Lines 487 and 493 call model_rebuild (Pydantic v2) or update_forward_refs (Pydantic v1) every time generate() is invoked without a config parameter. These operations should be performed once at module initialization time, not on every function call, to avoid unnecessary overhead.

2. Unused noqa directives: Lines 484, 485, 490, 491 have unused noqa: PLC0415 directives that should be removed per static analysis.

💡 Suggested approach for forward reference resolution

Consider moving the forward reference resolution to module initialization:

# Near the top of the module, after imports
if is_pydantic_v2():
    from datamodel_code_generator.model.pydantic_v2 import UnionMode
    from datamodel_code_generator.types import StrictTypes
    from datamodel_code_generator.config import GenerateConfig
    
    GenerateConfig.model_rebuild(_types_namespace={"StrictTypes": StrictTypes, "UnionMode": UnionMode})
else:
    from datamodel_code_generator.enums import UnionMode
    from datamodel_code_generator.types import StrictTypes
    from datamodel_code_generator.config import GenerateConfig
    
    GenerateConfig.update_forward_refs(StrictTypes=StrictTypes, UnionMode=UnionMode)

Then in the generate() function, simply construct the config without rebuilding:

if config is None:
    if is_pydantic_v2():
        config = GenerateConfig.model_validate(options)
    else:
        config = GenerateConfig(**options)

⛔ Skipped due to learnings

Learnt from: koxudaxi
Repo: koxudaxi/datamodel-code-generator PR: 2799
File: src/datamodel_code_generator/model/pydantic/__init__.py:43-43
Timestamp: 2025-12-25T09:22:22.481Z
Learning: In datamodel-code-generator project, defensive `# noqa: PLC0415` directives should be kept on lazy imports (imports inside functions/methods) even when Ruff reports them as unused via RUF100, to prepare for potential future Ruff configuration changes that might enable the import-outside-top-level rule.

Learnt from: koxudaxi
Repo: koxudaxi/datamodel-code-generator PR: 2799
File: src/datamodel_code_generator/util.py:49-66
Timestamp: 2025-12-25T09:23:08.506Z
Learning: In datamodel-code-generator, the is_pydantic_v2() and is_pydantic_v2_11() functions in src/datamodel_code_generator/util.py intentionally use global variable caching (_is_v2, _is_v2_11) on top of lru_cache for performance optimization. This dual-layer caching eliminates function call overhead and cache lookup overhead for frequently-called version checks. The PLW0603 linter warnings should be suppressed with # noqa: PLW0603 as this is a deliberate design choice.

Learnt from: koxudaxi
Repo: koxudaxi/datamodel-code-generator PR: 2681
File: tests/cli_doc/test_cli_doc_coverage.py:82-82
Timestamp: 2025-12-18T13:43:16.235Z
Learning: In datamodel-code-generator project, Ruff preview mode is enabled via `lint.preview = true` in pyproject.toml. This enables preview rules like PLR6301 (no-self-use), so `noqa: PLR6301` directives are necessary and should not be removed even if RUF100 suggests they are unused.

---

476-481: Remove unused noqa directive, but the mutual exclusion logic is correct.

Line 476 has an unused noqa: PLC0415 directive that should be removed. However, the mutual exclusion check itself is correctly implemented and provides a clear error message.

🔎 Proposed fix

-    from datamodel_code_generator.config import GenerateConfig  # noqa: PLC0415
+    from datamodel_code_generator.config import GenerateConfig

⛔ Skipped due to learnings

Learnt from: koxudaxi
Repo: koxudaxi/datamodel-code-generator PR: 2799
File: src/datamodel_code_generator/model/pydantic/__init__.py:43-43
Timestamp: 2025-12-25T09:22:22.481Z
Learning: In datamodel-code-generator project, defensive `# noqa: PLC0415` directives should be kept on lazy imports (imports inside functions/methods) even when Ruff reports them as unused via RUF100, to prepare for potential future Ruff configuration changes that might enable the import-outside-top-level rule.

---

451-451: Remove unused noqa directive.

The complexity warnings (PLR0912, PLR0914, PLR0915) are not being triggered, so the noqa directive can be removed.

🔎 Proposed fix

-def generate(  # noqa: PLR0912, PLR0914, PLR0915
+def generate(
     input_: Path | str | ParseResult | Mapping[str, Any],

⛔ Skipped due to learnings

Learnt from: koxudaxi
Repo: koxudaxi/datamodel-code-generator PR: 2799
File: src/datamodel_code_generator/model/pydantic/__init__.py:43-43
Timestamp: 2025-12-25T09:22:22.481Z
Learning: In datamodel-code-generator project, defensive `# noqa: PLC0415` directives should be kept on lazy imports (imports inside functions/methods) even when Ruff reports them as unused via RUF100, to prepare for potential future Ruff configuration changes that might enable the import-outside-top-level rule.