Improve query + path serialization

[drwpow]

Changes

Resolves #1533

Overhauls serialization to support advanced path serialization, and allows for an alternate, simpler querySerializer syntax according to the spec:

createClient({
  querySerializer: {
    array: { style: "form", explode: true },
    object: { style: "deepObject", explode: true },
    allowReserved: false,
  },
})

This change is backwards-compatible, meaning you can still provide a function to querySerializer(). However, it does introduce a ⚠️ minor breaking change in that deeply-nested objects/arrays aren’t supported (which hopefully no one was relying on, as that behavior is specifically outside the spec therefore there’s no predictable way to handle that).

How to Review

• Tests should pass

Checklist

• Unit tests updated
• docs/ updated (if necessary)
• pnpm run update:examples run (only applicable for openapi-typescript)

[changeset-bot]

🦋 Changeset detected

Latest commit: 119260b

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
openapi-fetch	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	119260b
Status:	✅  Deploy successful!
Preview URL:	https://52f72488.openapi-ts.pages.dev
Branch Preview URL:	https://query-serializers.openapi-ts.pages.dev

View logs

[drwpow]

Note (mostly for myself): I tested this simple RegEx approach, and a more low-level “parse-y” approach, and V8 seemed to favor this RegEx + .match() for performance. Before, this library used a static .replace(), and I wasn’t able to find a more performant alternative easily. There shouldn’t be any runtime impact (even splitting hairs).

Though I do value readability in code in general, when developing a library I think it is important to sweat the micro-optimizations, and not introduce runtime slowness just for the sake of readable code. I think that’s a luxury only afforded at the application level, not the library level.

[drwpow]

In the vein of performance, both Object.entries() and for … in are (really) fast. But for … in is about 2× faster. And though this is totally splitting hairs, I’d be remiss not to use whatever is an order of magnitude faster if there’s no discernable readability/complexity impact.

This was tested in current V8, and this smells like a temporary thing that will flatten out so both will probably be equally performant over time. But I saw the numbers today, and had to do it 🤷