Fix #184: Remove generic parameter from UseFieldConfig

[erikras-richard-agent]

Problem

Issue #184 reported a TypeScript compilation error after upgrading to v4.0.0:

Type 'UseFieldConfig' is not generic

This is a regression from the react-final-form v7.0.0 TypeScript migration.

Root Cause

In react-final-form v7.0.0, UseFieldConfig was changed to a non-generic interface. However, react-final-form-arrays was still trying to extend it with a type parameter: UseFieldConfig<FieldValue[]>

Solution

Remove the generic type parameter from UseFieldConfig in the type definition. Since UseFieldConfig already has properties like initialValue?: any and value?: any, it doesn't need to be generic.

Testing

• ✅ All existing tests pass (32/32)
• ✅ 100% code coverage maintained
• ✅ Build succeeds

Part of

🟠 HIGH: Fix v4.0.0 regressions (select multiple, TypeScript) - Plane task OSS-20

Fixes #184

Summary by CodeRabbit

• Refactor
  • Updated TypeScript type definitions for field array configurations. The base type inheritance has been adjusted, which may affect type compatibility and type inference for developers using TypeScript with field arrays.

[coderabbitai]

📝 Walkthrough

Walkthrough

Removed the generic parameter from UseFieldConfig inheritance in the UseFieldArrayConfig type definition. Previously, UseFieldArrayConfig<FieldValue> extended UseFieldConfig<FieldValue[]>; now it extends UseFieldConfig without a type argument, resolving a type compatibility issue with the parent library's non-generic base interface.

Changes

Cohort / File(s)	Summary
Type Declaration Update src/index.d.ts	Removed generic parameter from UseFieldConfig in UseFieldArrayConfig interface inheritance to align with parent library's type definitions and resolve typing errors.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

🐰 A type that once carried too much weight,
Now bounds with grace, no generic freight,
Arrays align with their config base,
Type errors vanish without a trace! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title 'Fix #184: Remove generic parameter from UseFieldConfig' directly addresses the main change: removing the generic type parameter from UseFieldConfig to resolve a TypeScript compilation error.
Linked Issues check	✅ Passed	The PR successfully resolves issue #184 by removing the generic parameter from UseFieldConfig, matching react-final-form's v7.0.0 API change where UseFieldConfig became non-generic.
Out of Scope Changes check	✅ Passed	The change is minimal and directly scoped to fixing issue #184: only the UseFieldArrayConfig interface declaration is modified to remove the generic parameter from UseFieldConfig.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/v4-regressions-typescript

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[erikras-richard-agent]

After reviewing PR #186 by @iamdey, I'm closing this PR.

Why? While this PR fixes the immediate symptom (the generic parameter error), PR #186 addresses the root cause by removing the duplicate type definitions in src/index.d.ts entirely and letting TypeScript generate types from the source files.

Root cause: The manual src/index.d.ts had diverged from the actual TypeScript types in src/types.ts, creating inconsistencies. My fix just patched one inconsistency, but the architectural problem remains.

Better solution: PR #186 eliminates the duplication and prevents future drift.

I should have investigated more deeply instead of applying a quick fix. Thanks to @iamdey for the thorough analysis!

Closing in favor of #186.

[erikras-richard-agent]

Closing in favor of the superior solution in PR #186.