Skip to content

Latest commit

 

History

History

oxide-openapi-gen-ts

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
docs
docs
 
 
src
src
 
 
.eslintrc.cjs
.eslintrc.cjs
 
 
README.md
README.md
 
 
package-lock.json
package-lock.json
 
 
package.json
package.json
 
 
tsconfig.json
tsconfig.json
 
 

README.md

@oxide/openapi-gen-ts

This is a TypeScript OpenAPI client generator built for use with schemas generated by Dropshot. It has not been tested on any other specs and is unlikely to handle them well.

Usage

npx @oxide/openapi-gen-ts@version <schema url or file> <output dir>

Note that fixing a version with @0.1.0 is important because you don't want your generated output to between runs. See the Versioning section below for details.

Interesting files

The core logic for looping over the spec and creating the methods is in src/client/api.ts and the mapping from OpenAPI schemas to TS types is in src/schema/types.ts. The mapping from OpenAPI schemas to Zod schemas is in src/schema/zod.ts.

The files in src/client/static/ are copied over to the client as-is during generation. We generate several distinct pieces:

File Description
Api.ts A Fetch-based TS client to the Oxide API
validate.ts Zod validators for API request and response types
msw-handlers.ts Helpers used to build a mock API with Mock Service Worker in the console repo

Why a custom generator?

We tried many existing generators, and while most worked in a basic sense, we found it hard to make customizations, whether through CLI flags, templates, or patching with patch-package. We decided to prototype our own TS generator after seeing other Oxide devs do the same for Rust (progenitor and oxide.rs) and Go (oxide.go). It quickly became clear that a special-purpose generator could be dramatically simpler than a general one, so writing one was easier than existing generators made it look.

The TypeScript client code will be written to oxide-api/src.

Versioning scheme

Generator versions on npm are semver-ish. Breaking changes to the generator's own API (not the generated output) should be major releases. Currently, the generator has no programmatic API and can only be used as a CLI app (e.g., through npx), so we will consider the CLI to be the external API.

Version bump Example changes
Major Breaking changes to CLI args or flags
Minor Semantic changes (i.e., modulo formatting) to generated output
Patch Internal changes or non-meaningful changes to generated output