This PR adds TypeScript type support for flat field arrays (arrays containing primitive values) in useFieldArray. Previously, useFieldArray only supported arrays of objects, but this change allows primitive arrays such as string[], number[], and multi-dimensional primitive arrays like string[][].

This is a type-only change with no runtime modifications.

Changes

Type Definition Update:

• Modified ArrayPathImpl in src/types/path/eager.ts to remove the primitive type restriction
• This allows ArrayPath to correctly resolve paths for primitive arrays

Before:

// Had to wrap primitive values in objects to use with useFieldArray
type FormValues = {
  items: {
    tag: string;
  }[]; // Nested object structure required
};

const { fields, append } = useFieldArray({
  control,
  name: 'items',
});

// fields type: ({ tag: string } & { key: string })[]
// append accepts: { tag: string } | { tag: string }[]

After:

// Can now use primitive arrays directly without wrapping
type FormValues = {
  tags: string[];
};

// ArrayPath<FormValues> now resolves to: 'tags'
// useFieldArray with name: 'tags' works correctly with full type safety

const { fields, append } = useFieldArray({
  control,
  name: 'tags',
});

// fields type: (string & { key: string })[]
// append accepts: string | string[]

Review Point: IDE Type Representation for Primitive Field Arrays

This change allows useFieldArray to support primitive arrays by modeling each field as an intersection type:

(string & { key: string })[]

This is necessary to attach the internal key property, but it has a noticeable impact on how types are displayed in IDEs.

Observed Issue

When hovering over fields in editors like VSCode, the type is expanded very verbosely due to the structural nature of string:

const { fields } = useFieldArray({ control, name: 'tags' });
// Hover tooltip shows:
const fields: ({
  readonly [index: number]: string;
  toString: () => string;
  charAt: (pos: number) => string;
  // ... all String prototype methods
  key: string;
})[]

This makes the type significantly harder to read and may be confusing for users, especially compared to object-based field arrays.

Current State

• This is a type-only change with no runtime impact
• Behavior at runtime is identical to plain strings
• The issue is limited to type representation and developer experience

Open Question for Reviewers

I’m not fully confident that this IDE experience is acceptable as-is.

I’d like feedback on:

• whether this type representation is acceptable to ship
• whether this should be documented as a known limitation
• or whether we should explore a different modeling approach before merging