URL is does not have the best results

[andreujuanc]

Hi,
Very cool library, but there are some issues with path concatenation.

new URL('c', 'https://a.com/b/'). => https://a.com/b/c
new URL('/c', 'https://a.com/b/'). => https://a.com/c

Which makes sense, but a lot of openapi specs use a base url with some sort of versioning or path like /v1 or even just /api.
And then the spec itself contains paths like /contacts which will be wrongly concatenated to the root instead of the base path.

For now I have manually removed the / of the path var within PrepareFetchUrl like so:

  PrepareFetchUrl(path: string): URL {
+  path = path.startsWith("/") ? path.slice(1) : path;
    let base = this.Config.baseUrl;
    if ("location" in globalThis && (base === "" || base.startsWith("/"))) {
      const { location } = globalThis as unknown as {
        location: { origin: string };
      };
      base = `${location.origin}${base.endsWith("/") ? base : `/${base}`}`;
    }

    return new URL(path, base);
  }

Not sure if this is the best solution, but works for me.

Best,

JC

[vladkens]

Hi @andreujuanc, thanks for raising this!

I actually had a similar request before. To be honest, I'm not completely sure what the "right" default behavior should be, since the current implementation follows the standard URL specification.

The library already allows overriding how URLs are resolved. For example, you can extend the client like this:

class MyClient extends ApiClient {
  PrepareFetchUrl(path: string) {
    return new URL(`${this.Config.baseUrl}/${path}`.replace(/\/{2,}/g, "/"))
  }
}

const api = new MyClient({ baseUrl: "https://example.com/v1" })
// will call: https://example.com/v1/pet/ instead of https://example.com/pet/
const pet = await api.pet.getPetById(404)

Maybe it would make sense to add a config flag in the generator so the client could either strictly follow new URL behavior or work more like simple string concatenation. The only question is what would be the best name for such a parameter?

[andreujuanc]

I think the problem is that URL behaviour is not aligned with openapi specs.
Maybe a simpler default concat should be used? Not sure why the base url must be formed via URL.
What do you think?
Also I would find that param very confusing. Even with a perfect name.