Module deps 

Computing the external crate dependencies the generated code requires.

Unlike Go — where go mod tidy resolves imports from the generated source automatically — Cargo never infers dependencies from use paths, and a path like http::StatusCode reveals neither the crate version nor the Cargo features a consumer must enable. The generator is the only component that knows exactly what it emitted, so it reports the crates (with versions and features) a consumer must add to Cargo.toml.

The set is derived by scanning the generated source for the crate-root paths and method calls the emitters produce. Deriving it from the actual output (rather than re-deriving from the IR) keeps this report automatically in step with the emitters: if they stop or start referencing a crate, the report follows without a parallel rule set to maintain.

The report lists every crate the generated file references. It deliberately does not read the consumer’s Cargo.toml to prune crates already present. Interpreting a consumer manifest (workspace inheritance, dev/target scopes, feature sufficiency) is Cargo’s job — so on --install-deps the CLI runs cargo add, which merges with any existing declaration.

Structs

Dependency

A crate the generated code references, with the version requirement and Cargo features a consumer must declare in Cargo.toml.

Functions

required_dependencies

Inspect generated code and return the external crates it references, in a stable order (shared model crates, then server crates, then client crates).