-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Generate JSON schema for app-server protocol #5063
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
All contributors have signed the CLA ✍️ ✅ |
I have read the CLA Document and I hereby sign the CLA |
recheck |
|
||
/// Optional Prettier executable path to format generated TypeScript files | ||
#[arg(short = 'p', long = "prettier", value_name = "PRETTIER_BIN")] | ||
prettier: Option<PathBuf>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a switch for cases that don't care about OpenAPI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@codex add a switch to control this, turn it on by default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary
- Added a
--json-schema
flag to the export CLI so JSON Schema generation can be toggled while defaulting to the previous behavior. codex-rs/app-server-protocol/src/bin/export.rsL9-L30
Testing
- ✅
just fmt
2cc4861
to
591304d
Compare
Add annotations and an export script that let us generate app-server protocol types as typescript and JSONSchema.
The script itself is a bit hacky because we need to manually label some of the types. Unfortunately it seems that enum variants don't get good names by default and end up with something like
EventMsg1
,EventMsg2
, etc. I'm not an expert in this by any means, but since this is only run manually and we already need to enumerate the types required to describe the protocol, it didn't seem that much worse. An ideal solution here would be to have some kind of root that we could generate schemas for in one go, but I'm not sure if that's compatible with how we generate the protocol today.