Fix useSWRInfinite pagination and header support (v7)

[tk1024]

Problem

The SWR code generator has several type safety and parameter handling issues:

1. Missing Pagination Support: useSWRInfinite implementation doesn't support pagination parameters:

   • swrFn doesn't accept parameters from the key loader
   • Pagination parameters cannot be passed to the API function
   • Makes infinite queries unusable for paginated APIs

2. Function Wrapping Bug: swrKeyLoader is incorrectly wrapped in an arrow function:

   • The wrapper ignores SWR's (pageIndex, previousPageData) arguments
   • Prevents proper pagination logic in infinite queries
   • Required workarounds to fix generated code

3. Missing Headers in useSWRInfinite: When headers: true is enabled, headers are not passed to the swrFn:

   • Headers defined in OpenAPI spec are ignored in infinite queries
   • Causes TypeScript compilation errors when headers are required
   • Runtime errors when API requires headers

4. Missing Headers in Mutation Fetchers: Mutation hooks and fetchers don't include header parameters:

   • useXXXMutation hooks don't accept headers
   • Mutation fetchers don't pass headers to API functions
   • Breaking for APIs that require headers in POST/PUT/DELETE operations

Solution

This PR fixes all issues:

1. Pagination Support: Generates swrFn that accepts pageParams from the key loader with proper type annotation extracted from GetterProp
2. Function Wrapping: Removes the incorrect arrow function wrapper from swrKeyLoader to allow SWR to pass pagination arguments correctly
3. Headers in useSWRInfinite: Includes header parameters in the swrFn between pageParams and options
4. Headers in Mutations: Includes headers in mutation hook signatures, fetcher functions, and properly passes them to API calls

Before

// useSWRInfinite: swrFn doesn't accept parameters and drops headers
const swrFn = () => listPets(params, options);
const swrKeyLoader = () => (isEnabled ? getKeyLoader() : null);

// Mutations: fetchers don't include headers
export const getCreatePetsMutationFetcher = (
  params: CreatePetsParams,
  options?: AxiosRequestConfig,
) => {
  return (_: Key, { arg }: { arg: CreatePetsBody }) => {
    return createPets(arg, params, options); // Missing headers!
  };
};

After

// useSWRInfinite: Type safe pageParams with headers support
const swrFn = ([_url, pageParams]: [string, ListPetsParams & { page: number }]) =>
  listPets(pageParams, headers, options);
const swrKeyLoader = isEnabled ? getKeyLoader() : () => null;

// Mutations: headers properly included
export const getCreatePetsMutationFetcher = (
  params: CreatePetsParams,
  headers: CreatePetsHeaders,
  options?: AxiosRequestConfig,
) => {
  return (_: Key, { arg }: { arg: CreatePetsBody }) => {
    return createPets(arg, params, headers, options); // Headers included!
  };
};

Changes

1. Fix useSWRInfinite swrFn parameter handling

• Separate path parameters (fixed values) from query parameters (pagination values)
• Generate swrFn that accepts ([_url, pageParams]) from the key loader
• Pass parameters correctly: operationName(pathParams, pageParams, options)

2. Add type annotation to pageParams

• Extract type name from GetterProp.definition (e.g., "params: ListPetsParams" → "ListPetsParams")
• Use never as fallback type for better type safety (causes compilation errors if params are missing when expected)
• Enables IDE autocomplete and compile-time type checking

3. Fix swrKeyLoader function wrapping bug

• The original implementation incorrectly wrapped the key loader: () => isEnabled ? getKeyLoader() : null
• This prevented SWR from passing (pageIndex, previousPageData) arguments to the key loader
• Fixed to return the actual key loader function: isEnabled ? getKeyLoader() : () => null
• This allows proper pagination parameter handling in infinite queries

4. Fix headers in useSWRInfinite

• Extract header parameters separately from other props
• Include headers in swrFn generation between pageParams and httpRequestSecondArg
• Ensures proper parameter order: operationName(pageParams, headers, options)

5. Fix headers in mutation fetchers and hooks

• Include GetterPropType.HEADER in swrProps filter for mutation hooks
• Include headers in swrMutationFetcherProperties for fetcher function parameters
• Generate proper parameter lists for both GET and POST/PUT/DELETE mutations
• Maintain correct parameter order: (params, headers, options) for fetcher signatures

6. Add comprehensive tests

• Unit tests for query parameter type extraction logic
• Unit tests for SWR builder functionality
• Regression tests for type safety with strict TypeScript settings
• Regression tests for swrKeyLoader function signature
• Tests for headers in infinite queries, regular queries, and mutations
• Test configuration with headers: true to catch header-related bugs

Testing

All tests pass successfully:

# Unit tests
yarn workspace @orval/swr test
# ✓ 5 tests passed

# Integration tests
yarn test:cli
# ✓ All generated code compiles with strict TypeScript

# Full test suite
yarn test:ci
# ✓ All tests pass

Affected Files

• packages/swr/src/index.ts - Core implementation (pagination, headers, mutations)
• packages/swr/src/client.test.ts - Unit tests for type extraction
• packages/swr/src/index.test.ts - Unit tests for builder
• packages/swr/vitest.config.ts - Test configuration
• packages/swr/package.json - Added test script and vitest dependency
• tests/regressions/swr.ts - Regression tests for type safety and headers
• tests/configs/swr.config.ts - Added petstoreWithHeaders test configuration

Breaking Changes

None. This PR fixes bugs and adds support for features that were previously non-functional:

• useSWRInfinite pagination was broken and unusable
• Headers in mutation fetchers were ignored even when headers: true was configured

After regeneration, previously broken functionality will now work correctly.

Related Issues

Fixes #2106

[tk1024]

I was unsure whether to target the master branch or the v7 branch.
If the release of v8 is expected to take some time, I would prefer to merge this as part of v7.

That said, this is just my preference, so I would like to defer the final decision to you.

Currently this PR is based on v7, but please let me know if it should instead be based on master.
Apologies for deviating from the guidelines in CONTRIBUTING.md.

[melloware]

Can you submit the PR against both v7 and V8 please.

[tk1024]

@melloware I've created PR #2587 for the master branch.

[melloware]

I will push a 7.17.0 with these changes

[tk1024]

Thanks for the quick turnaround!

[melloware]

ok 7.17.0 is on NPM if you want to give it a shot.