Evaluate flatc/FlatBuffers-driven codegen vs hand-rolled schema/type conformance oracles
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 1.3k
- Forks
- 79
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 117
Description
### Description of the task
Evaluate whether a schema-driven codegen pipeline — for example an internal FlatBuffers schema compiled with `flatc` — could replace the hand-rolled conformance oracles that keep the JSON schema, the generated Rust wire model, and the generated TypeScript wire types in agreement.
Today these artifacts are kept in sync by bespoke generators (`mxc_schema_gen`, `wxc_common::ts_emit`) plus hand-written conformance helpers and tests (`sdk/tests/unit/conformance-helpers.ts`, `wire-conformance*.test.ts`). @bbonaby raised in review of #580 that a single FlatBuffer schema could instead drive `flatc`-generated JSON schema, Rust types, and TypeScript types, with the FlatBuffer SDK verifying JSON — potentially reducing the amount of bespoke code we author and maintain.
The current no-third-party-generator approach is deliberate. The outcome of this task is a recommendation weighing that trade-off (maintenance cost and comprehensibility of the hand-rolled oracles vs. adopting an external generator/toolchain), not a commitment to switch.
### Additional context
- Non-blocking design discussion from the review of #580.
- Pre-existing surface, introduced in Phase 2.5 (SDK wire-type conformance).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.