Description
Problem Statement
Currently, all generated client methods in Ariadne-codegen include **kwargs: Any in their signatures. While this provides flexibility, it has several drawbacks:
Bypasses Python’s type-checking capabilities, making it harder to catch incorrect argument usage at development time.
Prevents static analysis tools like mypy and pylint from flagging incorrect parameter names or types.
Reduces the effectiveness of IDE autocompletion, as argument names and types are not explicitly defined.
Use Case
When using the generated client, developers may accidentally pass invalid arguments, and type checkers will not catch these errors. For example:
Current Behavior:
client.some_query(arg1="value", arg2="another", unexpected_arg=123) # No type errors detected
Since **kwargs: Any is present, tools like mypy will not flag unexpected_arg as an invalid argument.
Desired Behavior (Strict-Typed Methods):
def some_query(self, arg1: str, arg2: str) -> ResponseType:
...
With strict-typed methods, passing an unexpected argument would raise a type error:
client.some_query(arg1="value", arg2="another", unexpected_arg=123) # mypy: Unexpected keyword argument "unexpected_arg"
Proposed Solution
Introduce a configuration option in pyproject.toml to control this behavior:
[ariadne-codegen]
strict_client_methods = true # When enabled, omits **kwargs in generated methods
If strict_client_methods is false (default), maintain the current behavior.
If true, generate methods with explicitly defined parameters, omitting **kwargs.
Benefits
Improved Type Safety: Developers catch errors at development time rather than runtime.
Better IDE Support: Explicit method signatures improve autocompletion and type hinting.
Aligns with GraphQL’s Type-Safe Nature: GraphQL defines strict types, and the generated client should follow suit.
Backward Compatibility: The default setting maintains existing behavior, minimizing disruption.
Implementation Considerations
Ensure backward compatibility by keeping strict_client_methods = false as the default.
Choose a clear and intuitive name for the configuration option.
Update documentation to reflect the new feature.
Would love to hear thoughts from the maintainers on whether this aligns with the project’s direction. Thanks for considering this feature request!