New Oazapfts version broke generated code: Need support for endpoint parameter of type Array

[carleryd]

First off, thanks a lot for building this library! It's helped us tremendously and I really appreciate your work.

I ran into an issue with existing Open API schema code when updating to latest 4.2 version.
My schema endpoint code looks like this

  /users/{userIds}:
    parameters:
      - name: userIds
        in: path
        explode: false
        required: true
        schema:
          type: array
          items:
            type: string

which when running oazapfts generates

export function getUsers(userIds: string[], opts?: Oazapfts.RequestOpts) {
...
    }>(`/users/${encodeURIComponent(userIds)}`, {
...

but encodeURIComponent does not accept array as argument. This broke after the introduction of #103. Before this change, the generated code looked the same except here were no encodeURIComponent applied to orderIds.

In the meantime I'm going back to an earlier version. Please let me know what you think, thanks!

[Xiphe]

Hey @carleryd, sorry to hear that!

What was the last version that worked for you? (#103 was released along with v4.0.0, so probably v3.6.0 right?)

but encodeURIComponent does not accept array as argument.

Actually, according to mdn, it accepts "A string, number, boolean, null, undefined, or any object.".
But I can confirm that the typescript declaration only accepts string | number | boolean.

Can you give a little more context about the error?

Is it a typescript issue, where your code does not compile?
In this case we should open a bug-report at microsoft/TypeScript (And see if we build a workaround)

Or does the API you're connecting with expect the parameters to not be url-encoded?
In this case, what framework do you use for the API? We should check how the parameters should be transferred according to the OAS spec.

[carleryd]

Hi @Xiphe , thanks for getting back to me so quickly!

What was the last version that worked for you? (#103 was released along with v4.0.0, so probably v3.6.0 right?)

Yes I went back to v.3.6.0

Actually, according to mdn, it accepts "A string, number, boolean, null, undefined, or any object.".
But I can confirm that the typescript declaration only accepts string | number | boolean.

Oh yes you're right! I just notice the generated code had TypeScript errors, but looking into it more now I realise we don't even use these generated endpoints. We only use the types generated by oazapfts so that we are in sync with our clients which generate types using @rtk-query/codegen-openapi with oazapfts under the hood.

In conclusion it seems like all would be fine for us if TypeScript added support for array to encodeURIComponent because it does in practice. But I haven't dug into the problem further.

For the moment we don't need to upgrade, especially because the RTK Query codegen library is using a fork of 3.6.0 it seems, so we would want to use the same version as them.

Thanks again for your help!

[Xiphe]

OK, cool. I'm gonna open an issue at TypeScript for this.

Please let me know when this turns out to become a blocker.

[Xiphe]

Seems as if there already was a typescript discussion about this: microsoft/TypeScript#18159

And I currently don't want to questions decisions there. Will provide a fix for this on our end soon

[Xiphe]

While trying to fix this I realized that it want to spend a little more time to ensure we're spec compliant for all permutations of parameter serialization wether it's in query, path, cookie and header parameters.

I've pre-released my current fix as 4.3.1-formatted-path-params.1 so if you're blocked here you could try this one out but currently do not intend to move forward with that approach and will probably refactor the serialization stuff on a bit of a bigger scale. Can't tell when I'll find the time for that though.

[Xiphe]

Update: I have not made any progress here but it's still on my list

[Xiphe]

Just realized that it's exactly one year later and I haven't made progress with this and I'm afraid I wont find time for this in the forseeable future :(