Reviewing files that changed from the base of the PR and between d8e2fef and 6916fd7.

• tests/data/jsonschema/type_overrides_test.json is excluded by !tests/data/**/*.json and included by none

• src/datamodel_code_generator/__init__.py
• src/datamodel_code_generator/__main__.py
• src/datamodel_code_generator/arguments.py
• src/datamodel_code_generator/cli_options.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
• tests/main/test_main_general.py

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

616-616: LGTM! Clean parameter propagation for type overrides feature.

The type_overrides parameter is correctly added to the signature and passed through to the base parser. The implementation follows the established pattern used by other configuration parameters like type_mappings.

Also applies to: 718-718

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

195-195: LGTM! Consistent implementation across parsers.

The type_overrides parameter addition mirrors the implementation in JsonSchemaParser, maintaining consistency across parser subclasses. Both parsers correctly delegate the actual override logic to the base Parser class.

Also applies to: 296-296

tests/main/test_main_general.py (4)

21-21: LGTM! Consistent import addition for test validation.

The _type_overrides import follows the same pattern as _dataclass_arguments, enabling validation function testing for the new feature.

---

439-471: Excellent validation test coverage.

The test cases thoroughly validate the _type_overrides argument parser, covering:

• Model-level overrides: {"CustomType": "my_app.types.MyType"}
• Scoped overrides: {"User.field": "my_app.Type"}
• Multiple mappings and edge cases (empty dict)
• Comprehensive error scenarios with specific error messages

The test structure mirrors the existing _dataclass_arguments tests, maintaining consistency.

---

473-546: Well-documented tests highlighting important behavioral distinctions.

The integration tests effectively demonstrate and validate two key scenarios:

1. Model-level overrides (lines 473-512): Correctly verify that the overridden type model is NOT generated (assert "class CustomType" not in result) while the import IS added. The @pytest.mark.cli_doc with primary=True makes this the canonical documentation example.

2. Scoped overrides (lines 515-546): The comment at line 542 documents critical behavior: "Address model SHOULD still be generated (scoped override doesn't remove models)". This distinction—that User.address overrides only the field reference, not the model definition—is essential for users to understand.

These tests serve as both validation and documentation of the feature's nuanced behavior.

---

548-583: Comprehensive coverage of nested type scenarios.

This test validates that type overrides work correctly with container types (List[Tag]), ensuring:

• Overridden types aren't generated as models (assert "class Tag" not in result)
• Imports are correctly added (assert "from my_app import Tag" in result)
• The overridden type is properly referenced in nested contexts (array items)

This completes the test coverage for common override scenarios (model-level, scoped, and nested).

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

279-285: OpenAPIParser correctly forwards type_overrides to the base parser

The new type_overrides parameter is threaded through the OpenAPI parser’s constructor and passed to super().__init__ in the correct position alongside type_mappings, preserving existing behavior when it’s None.

Also applies to: 382-387

src/datamodel_code_generator/__init__.py (1)

497-504: Public generate() API extension for type_overrides is consistent and non-breaking

Adding type_overrides to generate() and forwarding it into the parser constructor is done cleanly and maintains backward compatibility (optional arg, default None). This aligns with the CLI/config plumbing and the base parser’s new parameter.

Also applies to: 749-751

src/datamodel_code_generator/cli_options.py (1)

171-172: CLI metadata for --type-overrides is correctly categorized

--type-overrides is registered under the Typing customization category, matching the argparse group and keeping the docs metadata in sync.

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

776-937: The current implementation correctly registers override imports through the property chain; the proposed fix is unnecessary.

The review's concern appears to be based on incomplete analysis of the import collection flow. When __apply_type_overrides sets data_type.import_ = override_import, these imports are automatically collected through the existing property chain:

1. data_type.imports property yields self.import_ if set
2. data_type.all_imports recursively yields from self.imports
3. field.imports collects from self.data_type.all_imports
4. model.imports property collects from all field imports
5. _finalize_modules appends model.imports to the module's imports

Crucially, model.imports is a non-cached property evaluated after __apply_type_overrides has modified the DataTypes in _process_single_module, so the override imports are properly included. Existing tests (test_type_overrides_model_level, test_type_overrides_scoped, test_type_overrides_nested_types) confirm this behavior by expecting the override imports to be present in the generated output.

No changes to the import registration logic are needed. The review's proposed diff, while well-intentioned, introduces unnecessary complexity that the current design already handles correctly through its property-based import collection system.