Refactor `crate::generate::Generator` per-target emission into modules #59

New issue

Open

opened 2026-05-19 00:29:32 +00:00 by timur · 0 comments

timur commented

2026-05-19 00:29:32 +00:00

Owner

Context

Follow-up from #56. The agent who modularized build/build.rs flagged (comment 33741) that per-target code emission (rust_types, rust_rpc, openrpc, js, rhai) does not live in build.rs — it lives in crate::generate::Generator. #56 was scoped "no behaviour change," so the per-target split couldn't be done there.

This issue tracks splitting Generator itself.

Goal

Extract per-target emission from the monolithic crate::generate::Generator into focused modules, one per output target:

generate/rust_types.rs — Rust struct/enum emission from OSchema types
generate/rust_server.rs — OSIS server handler emission
generate/rust_rpc.rs — RPC trait + handler emission (will need updating again once hero_rpc2 macro path lands in #55)
generate/openrpc.rs — OpenRPC 1.3.2 spec emission
generate/js.rs — JS/TS SDK class emission
generate/rhai.rs — Rhai binding emission
generate/python.rs — Python SDK emission (new target per #55; empty stub for now if hero_rpc2 work hasn't added the Python codegen yet)

Keep Generator itself as a thin orchestrator that loads schemas, picks targets per the build config, and dispatches to the per-target modules.

Constraints

No behaviour change. Same files emitted, same content, same paths.
recipe_server and petstore_server must build unchanged.
All existing unit + integration tests stay green.
Each new module ≤ ~500 LOC (same target as #56).
Public API of Generator stays stable.

Out of scope

Adding Python emitter logic — tracked in #55 as part of the hero_rpc2 vendor work. This issue only adds the empty python.rs placeholder.
Changing emission semantics for any existing target.
Touching build/build.rs further (handled in #56).

Acceptance

No file under crates/generator/src/generate/ exceeds ~500 LOC.
cargo build, cargo test, cargo clippy all green.
example/recipe_server and example/petstore_* build unchanged.
Public surface (Generator::from_dir, Generator::generate, etc.) unchanged.
Each per-target module has a 1-line doc comment naming the target and the source OSchema fields it consumes.

#56 — preceding build.rs split.
#55 — hero_rpc2 vendor + Python SDK (will modify the modules created here).
Parent META: hero_skills#262.

## Context Follow-up from [#56](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/56). The agent who modularized `build/build.rs` flagged ([comment 33741](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/56#issuecomment-33741)) that per-target code emission (`rust_types`, `rust_rpc`, `openrpc`, `js`, `rhai`) does **not** live in `build.rs` — it lives in `crate::generate::Generator`. #56 was scoped "no behaviour change," so the per-target split couldn't be done there. This issue tracks splitting `Generator` itself. ## Goal Extract per-target emission from the monolithic `crate::generate::Generator` into focused modules, one per output target: - `generate/rust_types.rs` — Rust struct/enum emission from OSchema types - `generate/rust_server.rs` — OSIS server handler emission - `generate/rust_rpc.rs` — RPC trait + handler emission (will need updating again once hero_rpc2 macro path lands in [#55](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/55)) - `generate/openrpc.rs` — OpenRPC 1.3.2 spec emission - `generate/js.rs` — JS/TS SDK class emission - `generate/rhai.rs` — Rhai binding emission - `generate/python.rs` — Python SDK emission ([new target per #55](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/55#issuecomment-33681); empty stub for now if hero_rpc2 work hasn't added the Python codegen yet) Keep `Generator` itself as a thin orchestrator that loads schemas, picks targets per the build config, and dispatches to the per-target modules. ## Constraints - **No behaviour change.** Same files emitted, same content, same paths. - `recipe_server` and `petstore_server` must build unchanged. - All existing unit + integration tests stay green. - Each new module ≤ ~500 LOC (same target as #56). - Public API of `Generator` stays stable. ## Out of scope - Adding Python emitter logic — tracked in [#55](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/55) as part of the hero_rpc2 vendor work. This issue only adds the empty `python.rs` placeholder. - Changing emission semantics for any existing target. - Touching `build/build.rs` further (handled in #56). ## Acceptance - [ ] No file under `crates/generator/src/generate/` exceeds ~500 LOC. - [ ] `cargo build`, `cargo test`, `cargo clippy` all green. - [ ] `example/recipe_server` and `example/petstore_*` build unchanged. - [ ] Public surface (`Generator::from_dir`, `Generator::generate`, etc.) unchanged. - [ ] Each per-target module has a 1-line doc comment naming the target and the source OSchema fields it consumes. ## Related - [#56](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/56) — preceding `build.rs` split. - [#55](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/55) — hero_rpc2 vendor + Python SDK (will modify the modules created here). - Parent META: [hero_skills#262](https://forge.ourworld.tf/lhumina_code/hero_skills/issues/262).