Expose the logic computing finalUrl

[ysulyma]

Description

I would like to remove hardcoded API routes from my code, and use this library instead. I no longer need these routes for the fetchers, but I still need them for testing code. Proposal is to export the internal logic for computing finalUrl.

Proposal

import fetchMock from "fetch-mock-jest";
import createClient from "openapi-fetch";

import { paths } from "./v1"; // (generated from openapi-typescript)

const { route } = createClient<paths>({ baseUrl: "https://myapi.dev/v1/" });

fetchMock.once(
  // "https://myapi.dev/v1/post/my-post?version=2"
  route("/post/{post_id}", {
    path: { post_id: "my-post" },
    query: { version: 2 },
  }),
  { /* ... */ }
);

Checklist

• I’m willing to open a PR for this (see CONTRIBUTING.md)

[drwpow]

I’d be fine with exposing this under a named import, e.g. import { createFinalUrl } from 'openapi-fetch. Probably for most peoples’ testing purposes they’d probably still need to maintain their own testing utility functions for their setup (e.g. which mocking tool they use), but I agree it’d be annoying to have to monitor parity with openapi-fetch’s implementation detail of how a URL is created.

[ysulyma]

@drwpow if this is exposed on the return of createClient, then it can include baseUrl in the output. Or would you prefer an API like createFinalUrl(url, {baseUrl, path, query})?

[drwpow]

Something like the latter, as this is probably more for testing purposes than anything else. And in that light, a more functionally-pure utility like your suggestion would be easier to deal with in general

[drwpow]

This should be exposed now in 0.3.0.