Fix TypeScript error in create-proxy component

[mattgperry]

The CreateVisualElement parameter type was too narrow (defaulting to CreateVisualElement<{}, "div">), causing type errors when passed to the generic createMotionComponent function. Changed to use explicit <any, any> type parameters to allow the proxy to work with any props and tag names.

[claude]

Code Review

This PR fixes a TypeScript type compatibility issue in create-proxy.ts by widening the CreateVisualElement parameter type from its default generic to CreateVisualElement<any, any>.

Analysis

The Problem:
The CreateVisualElement type has default generic parameters of {} for Props and "div" for TagName:

type CreateVisualElement<Props = {}, TagName extends keyof DOMMotionComponents | string = "div">

When passed without explicit type parameters, the parameter in createMotionProxy defaulted to CreateVisualElement<{}, "div">. However, createMotionComponent expects CreateVisualElement<Props, TagName> where Props and TagName are generic parameters that can be any type. This creates a type mismatch when the proxy passes the function to createMotionComponent (lines 41, 80).

The Solution:
The fix explicitly uses CreateVisualElement<any, any> to allow the proxy to work with any props and tag names, matching how it's used in create.ts:18:

createDomVisualElement as CreateVisualElement<Props, TagName>

Code Quality

✅ Minimal change - Single line modification that directly addresses the issue
✅ Consistent pattern - Matches existing usage in create.ts
✅ Type safety preserved - The function is still properly typed; any is acceptable here as the proxy needs to handle arbitrary component types

Concerns & Recommendations

1. Missing Test Coverage ⚠️

There are no unit tests for create-proxy.ts. Consider adding tests that:

• Verify the proxy works with various HTML elements (motion.div, motion.span, etc.)
• Test custom components with different prop types
• Ensure the caching mechanism works correctly
• Validate TypeScript type inference for consumers

2. Type Safety Trade-off ℹ️

Using any widens the type, which is pragmatic here but worth documenting. The proxy inherently needs to work with any component type, so this is appropriate. However, consider adding a comment explaining why any is necessary:

// Use any to allow proxy to work with arbitrary component types passed at runtime
createVisualElement?: CreateVisualElement<any, any>

3. Alternative Approach 💡

Consider if the interface could be designed differently to avoid any. For example, you could make MotionComponentConfig generic and thread the types through:

export interface MotionComponentConfig<Props = any, TagName extends keyof DOMMotionComponents | string = any> {
    createVisualElement?: CreateVisualElement<Props, TagName>
}

However, this would be a larger refactor and the current fix is pragmatic.

Security

✅ No security concerns identified

Performance

✅ No performance impact - this is a type-only change

Verdict

LGTM with suggestions ✅

The fix is correct and solves the immediate TypeScript error. The use of any is appropriate given the proxy's runtime behavior. Main suggestion is to add test coverage for this module to prevent regressions.

---

🤖 Review by Claude Code