Hello,

Thanks, :)

There is no build in way to handle this but implementing something like this per user basis is not a big of a deal. I don't think build in implementaiton for this would be practical or at least I am not sure how it could be implemented so that the behaviour would be generic across the users. But of course ideas and PRs are always welcome. :)

I would implement it roughly something like this to get this behaviour.

# in Cargo.toml add custom bin target to generate the spec from the types
[[bin]]
name = "gen-openapi"
path = "./src/gen_openapi.rs"

Then in the in the Rust code something like this. Or perhaps you can call the code in your main app to generate the OpenAPI doc. and then write it to the file. You could easily share code between your app and binary which would generate the write the code to a file.

// in ./src/gen_openapi.rs
fn main() {
    let doc = gen_my_openapi();
    fs::write("./path/to/file", doc);
}

// in /src/openapi.rs 
fn gen_my_openapi() -> String {
  #[derive(Deserialize, ToSchema)]
  struct Person {
      /// Id of person
      id: i64,
      /// Name of person
      name: String,
  }

  #[derive(OpenApi)]
  #[openapi(schemas(components(Person)))]
  struct ApiDoc;

  ApiDoc::openapi().to_pretty_json().unwrap()
}

Then you can call the code from your terminal session with.

 cargo run --bin gen-openapi

While this is en extra step. But I concur it is better to have it as manual step than automatically write to the file when values for macros are changed. And if that was the approach then the runtime modifiers could not be used. This step could also be used together with cargo watch if necessary and needed with automatic document updates.

Aternatively if it is seen better that the API doc is dumped to a file everytime you build your application one could leverage usage of build.rs. The similar generation and file writing could be done within the build.rs file what is executed everytime the application is built.

Export OpenAPI spec at build time #214

Description

Activity

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions