feat: improve fetchOptions type definition

[anhlecongtran]

This PR addresses issue #6869.

The current fetchOptions type definition includes Record<string, any>, which reduces TypeScript type safety and IDE autocomplete support. This change updates the type definition to rely on RequestInit, which aligns with the Fetch API standard and improves developer experience.

Changes:

• Removed Record<string, any> from the fetchOptions type definition.
• Kept the existing RequestInit-based typing.

Related Issue:
#6869

---

Summary by cubic

Tighten fetchOptions typing to only allow RequestInit fields, removing Record<string, any>. This improves type safety and IDE autocomplete, and may surface invalid option usage at compile time.

Description

• Summary of changes
  • Removed Record<string, any> from fetchOptions.
  • Kept fetchOptions as Omit<RequestInit, 'body' | 'headers' | 'method' | 'signal'>.
• Reasoning
  • Aligns with the Fetch API.
  • Improves DX via stricter types and better autocomplete.
• Additional context
  • Addresses Improve fetchOptions type definition for better autocomplete, type safety, Next.js extensions #6869.

Docs

Update /docs/ to state that fetchOptions accepts only RequestInit fields (excluding body, headers, method, signal). Remove any mention of arbitrary custom keys.

Testing

• No runtime behavior changes.
• Add or update a small TypeScript type test to ensure only valid RequestInit keys are accepted and invalid keys fail type-check.

Semantic version impact

Breaking (types-only): narrows the public type and can cause new TypeScript errors for consumers passing non-RequestInit fields.

^{Written for commit 0573372. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 1 file

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}