feat(bridge-gen): configurable derives and optional client feature

[xsistens]

Motivation

When consuming generated bridge SDKs from a frontend (e.g. a Dioxus fullstack app), I ran into two friction points:

1. The generated types can't be used without pulling in the full networking stack. All types, IntoValue/FromValue impls, and the client struct live in a single flat module with hard dependencies on golem-client, golem-common, and golem-wasm. If you only need the data types for serde on the WASM side of a fullstack app, you're forced to compile the entire Golem client stack for a target that can't use it.

2. No way to add derives to generated types. Bridge SDK types only get Debug and Clone. In practice you almost always need PartialEq for diffing/caching in a reactive UI, and sometimes Eq/Hash for map keys. This currently requires post-generation patching or wrapper types.

Changes

Optional client feature for Rust bridge SDKs

The generated Cargo.toml now has a [features] section:

[features]
default = ["client"]
serde = ["dep:serde"]
client = ["dep:golem-client", "dep:golem-common", "dep:golem-wasm", "dep:reqwest", "dep:reqwest-middleware"]

• client (default): Full networking — the agent struct, configure(), IntoValue/FromValue impls, and all golem dependencies.
• serde: Only serde derives on the data types. No networking deps.

The client struct, configure(), IntoValue/FromValue, and all golem imports are gated behind #[cfg(feature = "client")]. Data type definitions (structs, enums) are always available regardless of features.

This lets downstream crates do:

# WASM/frontend — types only, no networking
my-bridge-client = { path = "...", default-features = false, features = ["serde"] }

# Server — full client
my-bridge-client = { path = "...", features = ["client"] }

Configurable derive rules via golem.yaml and CLI

New additionalDerives field in golem.yaml bridge SDK targets:

bridgeSdks:
  rust:
    agents: [MyAgent]
    additionalDerives:
      - { pattern: ".*", derives: ["PartialEq"] }
      - { pattern: "^UuidUuid$", derives: ["Eq", "Hash"] }

Each rule is a regex pattern matched against type names. Matching derives are merged and deduplicated. Also available via CLI:

golem-cli generate-bridge --derive-rule ".*=PartialEq" --derive-rule "^UuidUuid$=Eq,Hash"

BridgeGeneratorConfig plumbing

The BridgeGenerator trait's new() method now takes a BridgeGeneratorConfig struct that carries the derive rules. The TypeScript generator accepts but ignores it (prefixed _config) since the feature is Rust-specific for now. Config flows from YAML parsing through BridgeSdkTarget and CustomBridgeSdkTarget all the way to the generator.

Files changed

File	What
bridge_gen/mod.rs	DeriveRule, BridgeGeneratorConfig types; updated BridgeGenerator trait
bridge_gen/rust/mod.rs	Feature gating, base_derive_attrs(), optional deps in Cargo.toml generation
bridge_gen/typescript/mod.rs	Accept _config param (no-op)
app/build/gen_bridge.rs	Wire config from manifest/custom targets to generators
app/context.rs	Default config for REPL bridge generation
command.rs	--derive-rule CLI flag
command_handler/bridge.rs	Parse --derive-rule format, pass config through
command_handler/mod.rs	Pass new arg to bridge handler
model/app.rs	derive_rules on target structs
model/app_raw.rs	DeriveRuleRaw serde type, new YAML field

Testing

Tested against a Dioxus 0.7 fullstack app with 7 bridge SDK agents:

• Server target compiles with features = ["client"] — full networking
• WASM target compiles with default-features = false, features = ["serde"] — types only
• additionalDerives with PartialEq on all types and Eq/Hash on UUIDs — verified in generated output
• Existing behavior unchanged when no config is provided (defaults to current derives, client feature on by default)

[vigoo]

I will provide a more detailed review as well, but some preliminary comments:

• I think this is a very useful addition and it is compatible with our Golem 1.6 plans to be able to generate bridge libraries that are usable from agents as well (compiles to wasm, uses wasi:http through wstd or fetch, etc)
• that said, the feature gate as in the PR is not good enough, because we use some special types from golem-common/golem-wasm for multimodal, unstructured text and binary. so instead of fully gating the golem libraries, we should feature gate them as well; this probably requires introducing a new feature flag in golem-common to filter out even more things (golem-client already depends on it with a limiting feature flag)
• The fix to match duplicated type definitions should not be like this - instead, we should not generate them in the first place :) so we need to find the root cause of that

[xsistens]

Thanks for the reply @vigoo I really appreciate this. I double checked the issue with the duplicated type definitions and it was a stupid mistake on my side, I'm sorry for bothering you with it. I removed the adjustments in this PR for this part and was able to fix it on my side. There is no rush from my side to push this in any way, we can take our time and polish it they way it's best for golems future plans. My main goal was to check with you if the general idea is reasonable and fits to your future plans, that's why I'm happy to hear that you had similar plans for the future anyway. Im not sure if I can make the required adjustments for the feature gates on my own (i just started learning rust) but I'm happy to assist where I can.

[vigoo]

I will get back to this PR after 1.5.0 (and possible include it in a patch release)