Feature request: Option for generating schema only

[ChilloManiac]

Hi

I'm working on an API where we write do api-spec-first development. Currently we are manually creating the schemas using Zod and keeping them aligned. This tool seems promising, but the generated EndpointSchema and ApiClient is unneeded, it would be neat if there was a flag to only generate the schemas.

[astahmer]

got it, I see the point.

that's why there are some comments, so that you can just find their start/end index and remove what's in between
comments like

• // <EndpointByMethod> and // </EndpointByMethod>
• // <EndpointByMethod.Shorthands> and // </EndpointByMethod.Shorthands>
• // <ApiClientTypes> and // </ApiClientTypes>
• // <ApiClient> and // </ApiClient>

so, for example, if you just want to keep the schemas + endpoint definitions, you can do something like:

const schemasOnlyFile = generated.slice(0, generated.indexOf("// <EndpointByMethod>"))

---

also, if you just want the schemas with a runtime, without even the endpoints definitions, you should directly use the tool that is used internally: https://github.com/sinclairzx81/typebox-codegen see the live online demo here https://sinclairzx81.github.io/typebox-workbench/

[the-ult]

The comments are usefull.
But it would be great if the generated code wouldn't need any altering.

Is it possible to add an option to skip the APIClient and/OR Endpoints?

The difference with typebox-codegen seems like that's only typescript -> runtime..
Instead of OpenAPI -> runtime, like this great library.

[astahmer]

feel free to send a PR that adds an option / CLI flag for that

[the-ult]

I'll see/hope to make some time in the near future and see if I can contribute.
(bit to busy atm I'm afraid)

[astahmer]

done here #74

[jpierson-at-riis]

@astahmer, due to issues pointed out in #12 (comment) when using the generated output from a Node.js project, it would be nice to be able to exclude the ApiClient but to include the individual endpoint types. I'm using these generated types on both client and server because I'm not happy with any of the other solutions out there which typically do not want to use the OpenAPI spec as the source of truth.

I typically don't use the ApiClient call by the way in any of the many projects that I've used typed-openapi in and opt instead to just using the generated types. Recently when working on an Express project I reached for using the generated method prefixed endpoint schemas in order to help enforce types on the Express request handlers. Although I'm not that happy with the current results trying to use this together with Express, this method has shown some utility, and I was planning to use it until some better solution surfaced. While being able to use --schemas-only definitely resolves my original problem with the removal of reliance on the browser specific Response type, it creates another in that it removes the endpoints. By being able to exclude just the ApiClient or somehow generating an ApiClient which is compatible with Node.js projects by not relying on the DOM Response type directly would help workaround my issue and perhaps make the project a bit more flexible for different reasonable use-cases.

[astahmer]

you can probably use the // <ApiClient> and // </ApiClient tags and remove anything in between in the generated file, I added those markers exactly for this kind of use case

ask gpt to generate a script that will read the file and remove the content after finding those strings and then run it after using typed-openapi

[joshdavenport]

I did something very similar (but for a different area of the output) in a past project but used replace-in-file to do it. So my npm script entry looked like:

typed-openapi ./public/openapi.json --output ./src/types/index.d.ts && replace-in-file --configFile ./api.replace.config.js ./src/types/index.d.ts`

With that mentioned replace config being:

module.exports = {
  from: /\/\/ <ApiClientTypes[^]+/,
  to: '',
};

I imagine pretty easily adaptable to your scenario. Or just use sed if you know that is always avaiable, etc.

[jpierson-at-riis]

Cool, I may use this. I was thinking of using the zod client library instead since it has more validations included but it looks like Zodios is outdated. Then I found openapi-ts-rest but that wouldn't even pull from npm. Seems like the ecosystem for generating things based on the OpenAPI spec is somewhat fragile at this point unfortunately so I'll probably come back to one of these workarounds for now until I can find something more robust which combines Zod with OpenAPI spec first that can work for both Node.js and the browser. Thanks @astahmer and everybody else who has contributed to this project, I've used it quite a bit and it has been a bit help!

[astahmer]

@jpierson-at-riis added a new --include-client flag in this PR