[REQ] Export URL path construction functions in typescript-fetch generated client

Is your feature request related to a problem? Please describe.

When using the typescript-fetch generator with Mock Service Worker (MSW) for API mocking, I face a duplication problem. Both the generated API client and MSW mock handlers need to construct the same URL paths, but currently the path construction logic is embedded directly within the API methods and not exposed for external use. ( https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/typescript-fetch/apis.mustache#L282 )

This leads to:

• Code duplication: I have to manually reimplement the same URL path patterns in MSW handlers
• Maintenance burden: When API paths change in the OpenAPI spec, I need to update both the generated client and the mock handlers
• Contract drift: Risk of inconsistencies between client and mock paths due to manual implementation
• Reduced type safety: MSW handlers lose the type-safe path construction that the generated client enjoys

Describe the solution you'd like

I'd like the typescript-fetch template to generate and export standalone functions for URL path construction that can be reused by MSW mock handlers.

For example, given an OpenAPI path /pets/{id}, the generator should produce:

// Currently generated
export class PetApi {
  getPetById = (id: string): Promise<Pet> => {
    // path construction inline
  }
}

// Proposed additional exports
export const paths = {
  getPetById: (id: string): string => `/pets/${encodeURIComponent(id)}`
}

Or even better, export a more structured approach:

export const endpointBuilders = {
  pets: {
    getPetById: (params: { id: string }) => `/pets/${encodeURIComponent(params.id)}`,
    listPets: (params?: { limit?: number }) => `/pets${params?.limit ? `?limit=${params.limit}` : ''}`
  }
} as const;

This would allow MSW handlers to reuse the exact same path construction logic:

import { endpoints } from './generated-client';

// In MSW handler
rest.get(endpoints.pets.getPetById({ id: ':id' }), (req, res, ctx) => {
  // Mock implementation
})

Describe alternatives you've considered

1. Manual path construction: Currently reimplementing paths in MSW handlers, but this breaks when OpenAPI spec changes and requires manual synchronization.

2. Runtime path extraction: Attempting to intercept and extract URLs from actual requests, but this doesn't work for request matching in MSW setup phase.

3. Custom template modifications: Maintaining a fork of the template with this functionality, but this adds maintenance overhead and version upgrade complexity.

4. External path generation tools: Using separate libraries to generate paths, but this creates dependency on additional tools and potential consistency issues.

Additional context

This feature would significantly improve the development experience when using OpenAPI Generator in combination with API mocking solutions like MSW. It supports the growing practice of contract-first API development where the same API specification drives both client implementation and testing infrastructure.

The change should be backward compatible - adding new exports without breaking existing generated client functionality. The path construction functions should handle all OpenAPI path features including:

• Path parameters with proper encoding
• Query parameters (optional)
• Validation against the OpenAPI schema

This approach aligns well with the principles of high cohesion and low coupling, as it separates path construction concern from API client logic, making both the generated client and mocking setup more maintainable.

Start with the typescript-fetch template at modules/openapi-generator/src/main/resources/typescript-fetch/apis.mustache#L282, where path construction is currently embedded in API methods. Decide the export shape before implementing it, then ensure generated clients retain existing behavior while exposing reusable builders for encoded path parameters and query parameters. The issue is done when the new exports are backward compatible and cover the listed OpenAPI path features.