Generator: generate_server_lib_rs should auto-discover hand-written sibling modules (mirrors generate_sdk_lib_rs) #93

Open
opened 2026-05-20 09:46:21 +00:00 by timur · 1 comment
Owner

Problem

When the generator emits crates/<name>_server/src/lib.rs, it lists only the codegen-managed modules. Any hand-written sibling modules (e.g. engine, seed, services, tracing_layer, custom domain logic) get stripped on regen.

Found by the hero_logic#46 agent during the template-pattern migration — they had to re-emit hero_logic_server/src/lib.rs from a build.rs post-process step to restore the four hand-written sibling modules. That hack is what this issue removes.

The parallel emitter for the SDK (generate_sdk_lib_rs) already solves this: it auto-discovers modules via //! @sdk-feature: doc-comment markers. The server emitter just needs the same trick.

What to do

Mirror the SDK emitter's discovery approach in generate_server_lib_rs:

  1. Before re-writing lib.rs, scan crates/<name>_server/src/ for any .rs file containing a //! @server-feature: (or similar) marker doc comment.
  2. Emit pub mod <discovered>; lines for those alongside the codegen-managed modules.
  3. The marker convention should match SDK's pattern for symmetry (@server-feature: mirrors @sdk-feature:).

Affected services

Any service whose _server crate has hand-written modules beyond the codegen-managed ones:

  • hero_logic_server — has engine, seed, services, tracing_layer
  • Future services that need similar (admin authentication helpers, custom middleware, background workers, …)

Acceptance

  • hero_logic_server/src/lib.rs is fully codegen-managed; the four sibling modules survive regen via the marker discovery.
  • hero_logic's build.rs drops the lib.rs post-process step.
  • New services adding a hand-written sibling module just need the doc marker; no build.rs hacks.
  • Existing services without extra modules behave identically.
  • Discovery: hero_logic#46 PR body item 3
  • Existing pattern to mirror: generate_sdk_lib_rs in the generator (post-#59 split, lives under crates/generator/src/generate/)
## Problem When the generator emits `crates/<name>_server/src/lib.rs`, it lists only the codegen-managed modules. Any hand-written sibling modules (e.g. `engine`, `seed`, `services`, `tracing_layer`, custom domain logic) get **stripped on regen**. Found by the [hero_logic#46](https://forge.ourworld.tf/lhumina_code/hero_logic/pulls/46) agent during the template-pattern migration — they had to re-emit `hero_logic_server/src/lib.rs` from a `build.rs` post-process step to restore the four hand-written sibling modules. That hack is what this issue removes. The parallel emitter for the SDK (`generate_sdk_lib_rs`) **already solves this**: it auto-discovers modules via `//! @sdk-feature:` doc-comment markers. The server emitter just needs the same trick. ## What to do Mirror the SDK emitter's discovery approach in `generate_server_lib_rs`: 1. Before re-writing `lib.rs`, scan `crates/<name>_server/src/` for any `.rs` file containing a `//! @server-feature:` (or similar) marker doc comment. 2. Emit `pub mod <discovered>;` lines for those alongside the codegen-managed modules. 3. The marker convention should match SDK's pattern for symmetry (`@server-feature:` mirrors `@sdk-feature:`). ## Affected services Any service whose `_server` crate has hand-written modules beyond the codegen-managed ones: - `hero_logic_server` — has `engine`, `seed`, `services`, `tracing_layer` - Future services that need similar (admin authentication helpers, custom middleware, background workers, …) ## Acceptance - `hero_logic_server/src/lib.rs` is fully codegen-managed; the four sibling modules survive regen via the marker discovery. - `hero_logic`'s `build.rs` drops the lib.rs post-process step. - New services adding a hand-written sibling module just need the doc marker; no build.rs hacks. - Existing services without extra modules behave identically. ## Related - Discovery: [hero_logic#46 PR body](https://forge.ourworld.tf/lhumina_code/hero_logic/pulls/46) item 3 - Existing pattern to mirror: `generate_sdk_lib_rs` in the generator (post-#59 split, lives under `crates/generator/src/generate/`)
Author
Owner

Implementation pushed on branch issue-91-92-93-generator-fixes. Bundled with the other two generator fixes from the same root (the hero_logic#46 build.rs post-process patches).

  • #91 title format is now <service> - <domain> (space-dash-space). Aggregate strip logic updated to match.
  • #92 emits servers[] from service.toml [[binaries.sockets]] with protocol = "openrpc", URL shape unix://${HERO_SOCKET_DIR}/<path> so openrpc_client!::connect() resolves via resolve_socket_path_with_override. Per-domain narrows by binary name suffix _<domain>; aggregate keeps the union.
  • #93 generate_server_lib_rs discovers hand-written *.rs / <dir>/mod.rs modules carrying //! @server-feature: and emits pub mod lines for them. Marker-required (server crates carry internal helpers; SDK-style discover-everything would over-expose).

Verified via example/recipe_server regen + cargo build --workspace clean + cargo test -p hero_rpc_generator --lib (131 passed).

Implementation pushed on branch [issue-91-92-93-generator-fixes](https://forge.ourworld.tf/lhumina_code/hero_rpc/src/branch/issue-91-92-93-generator-fixes). Bundled with the other two generator fixes from the same root (the hero_logic#46 build.rs post-process patches). - **#91** title format is now `<service> - <domain>` (space-dash-space). Aggregate strip logic updated to match. - **#92** emits `servers[]` from `service.toml` `[[binaries.sockets]]` with `protocol = "openrpc"`, URL shape `unix://${HERO_SOCKET_DIR}/<path>` so `openrpc_client!::connect()` resolves via `resolve_socket_path_with_override`. Per-domain narrows by binary name suffix `_<domain>`; aggregate keeps the union. - **#93** `generate_server_lib_rs` discovers hand-written `*.rs` / `<dir>/mod.rs` modules carrying `//! @server-feature:` and emits `pub mod` lines for them. Marker-required (server crates carry internal helpers; SDK-style discover-everything would over-expose). Verified via `example/recipe_server` regen + `cargo build --workspace` clean + `cargo test -p hero_rpc_generator --lib` (131 passed).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_rpc#93
No description provided.