1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
//! <!-- The primer is the repository's README, which is also this crate's
//! front page on crates.io and docs.rs. What follows it here is the part a
//! reader wants *after* deciding to use the crate: the map of the API, and
//! what a feature is allowed to do to it. -->
//!
//! # The API
//!
//! The six things a caller learns:
//!
//! - [`Document`] — the document, corrected and resolved.
//! [`Document::from_blob`] takes the reduction back off the bytes
//! [`Document::to_blob`] wrote.
//! - [`Values`] — arguments for one operation, under the document's own names.
//! A CLI builds one from `ArgMatches`; a generated wrapper builds one from
//! typed arguments.
//! - [`Invocation`] — an operation and values that satisfy it. Making one is
//! the validation; [`Invocation::request`] is then a rendering.
//! - [`Plan`] — the gate. A read runs on sight; a write runs only once
//! confirmed, and until then a dry run prints the exact bytes a confirmed
//! run would send.
//! - `tree::commands` and `tree::dispatch` — the clap tree, and the trip back.
//! - [`SyncClient`] / [`AsyncClient`] — where the request meets the network.
//!
//! The document is data: an operation is a value in a list, not a branch
//! someone wrote, so there is no chance of the CLI disagreeing with the
//! document it shipped with, and the tree, the completion and the request
//! builder all read the same list.
//!
//! Reading that list out of YAML is not, however, something a shipped binary
//! should do on every invocation, and under the default feature set it is not
//! something a shipped binary compiles. `Document::load` is the expensive door
//! and `document` is what opens it; [`Document::from_blob`] is the door a
//! binary uses, and it takes the reduction a bless step already wrote down.
//!
//! # What a feature may do
//!
//! Every feature adds and removes whole items and never changes one. No type
//! on this page gains a variant or a field with one, so a caller who matches
//! an error of this crate exhaustively writes the same match in every build,
//! and what the docs say about a type they can see is true of every build that
//! has it.
//!
//! `clap` is on by default because most adopters want the command tree; a
//! crate that only wants typed calls turns it off and links no argument
//! parser. `document` and `generate` belong to the bless step, and a shipping
//! binary that enabled either would compile a YAML parser, an OpenAPI object
//! model and a code generator it can never reach.
/// `bon`, for generated code to name the builder macro through.
///
/// A generated `ops.rs` writes `#[bon(crate = ::typed_openapi::bon)]`, so the
/// crate holding it turns the builder on with one feature and adds no
/// dependency of its own — and the proc-macro version stays the one the
/// generator emitted syntax for.
pub use bon;
pub use ;
pub use LoadError;
pub use ;
pub use ;
pub use ;
/// `regress`, for generated code to name the regex engine through.
///
/// A generated `types.rs` enforces a schema's `pattern` inside `FromStr`, and
/// the generator points every such check at `::typed_openapi::regress`, so the
/// crate holding the generated code adds no dependency of its own — and the
/// engine stays the one the generator emitted syntax for, which is the same one
/// [`Scalar::parse`] runs the command line's values through.
pub use regress;
pub use ;
pub use Scalar;
pub use ;
pub use ;