Ship more detailed types? Codegen from OpenAPI-spec?

[KATT]

Hey gang!

Looking at the typedefs of this SDK, I see a big void of actual type-safety:

Even looking at the docs I still don't know what different endpoints are supposed to return without actually invoking the call. The problem with that is that we won't have any reconciliation reports in our sandbox environment.

This example above is just in order to showcase and issue and grokking that is a separate issue.

Suggestion: You shouldn't need to manually write the implementation of every endpoint and instead be able to automatically generate a typesafe SDK based on your OpenAPI-schema using something like the openapi-generator.

Automating this would likely:

• Greatly reduce the amount of effort needed to put into this SDK
• Improve your quality of life maintaining it
• Remove inconsistencies between the actual API & this SDK
• Improve the experience for your customers

[christos97]

Hello checkout.com team,

Please don't do typechecking with primitives.
Do you manually handle/update your *.d.ts files?

source

[ioan-ghisoi-cko]

Thanks for the feedback @christos97 Will look into updating this.

[ioan-ghisoi-cko]

@KATT The very minimal type defs were intentional. You can use our API reference to see details about the payloads. We are also exploring generators or full types support as well.

[tbartley]

Type safety reduces the maintenance burden on consumers of SDKs enormously. It would be great to see an improvement as suggested here.

[armando-rodriguez-cko]

We will try to implement this improvement soon.

[tdeaks]

Hi, I'm using this SDK for a tool I'm building, and immediately noticed the loose typing. I've forked the repo and started a TypeScript migration on my fork. Would you be open to reviewing it as a PR, or a short series of PRs? Rough shape:

• Runtime behaviour provably the same with the existing mocha suite running unchanged against the converted source.
• tsc emitting the .d.ts files at build time, replacing the hand-maintained types/dist tree and the release-time rsync, so declarations can't drift from the code.
• Request/response models sourced from the OpenAPI spec you publish on the API reference site.

Happy to split it however suits you, e.g. toolchain first, then one PR per product area. If it's not something you want upstream, no problem at all, I'll keep the fork up to date myself. Thought it was worth asking, I'll be doing the work either way so if you are open to it, let me know :)