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
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
//! splicer — plan and generate WebAssembly component compositions.
//!
//! Most users only need the two top-level entry points:
//!
//! - [`splice`] — splice middleware into an existing composition.
//! - [`compose`] — synthesize a composition from N components.
//!
//! Both take a typed request struct and return a typed output struct
//! whose `wac_deps` field is shaped to be handed straight to
//! [`wac_resolver::FileSystemPackageResolver`](https://docs.rs/wac-resolver)
//! (or formatted into a `wac compose ... --dep ...` shell command).
//!
//! Advanced users who want more granular control can reach for the
//! lower-level building blocks under [`lowlevel`], or import the
//! shared types from [`types`].
//!
//! # Quick start: shell out to `wac compose`
//!
//! ```no_run
//! # fn main() -> anyhow::Result<()> {
//! let rules_yaml = std::fs::read_to_string("splice.yaml")?;
//! let out = splicer::splice(splicer::SpliceRequest {
//! composition_wasm: "composition.wasm".into(),
//! rules_yaml,
//! package_name: "example:composition".into(),
//! splits_dir: "./splits".into(),
//! skip_type_check: false,
//! })?;
//!
//! std::fs::write("output.wac", &out.wac)?;
//! println!("{}", out.wac_compose_cmd("output.wac"));
//!
//! for adapter in &out.generated_adapters {
//! println!(
//! "generated adapter for middleware '{}' at {}",
//! adapter.middleware_name, adapter.adapter_path,
//! );
//! }
//! # Ok(())
//! # }
//! ```
//!
//! # Programmatic compose with the `wac` crates
//!
//! [`SpliceOutput::wac_deps`] is shaped to plug straight into
//! [`wac_resolver::FileSystemPackageResolver`](https://docs.rs/wac-resolver/0.9/wac_resolver/struct.FileSystemPackageResolver.html)
//! — the keys are fully-qualified WAC package keys (e.g. `"my:srv-a"`),
//! the values are `PathBuf`s. The full programmatic pipeline that
//! mirrors `wac compose` looks like this:
//!
//! ```ignore
//! use std::collections::HashMap;
//! use wac_parser::Document;
//! use wac_resolver::{packages, FileSystemPackageResolver};
//! use wac_graph::EncodeOptions;
//!
//! # fn run(out: splicer::SpliceOutput) -> anyhow::Result<Vec<u8>> {
//! // 1. parse the WAC source splicer emitted
//! let doc = Document::parse(&out.wac)?;
//!
//! // 2. discover which package keys the document references
//! let keys = packages(&doc)?;
//!
//! // 3. resolve those keys against splicer's wac_deps map
//! let overrides: HashMap<String, std::path::PathBuf> =
//! out.wac_deps.into_iter().collect();
//! let resolver = FileSystemPackageResolver::new(".", overrides, true);
//! let pkgs = resolver.resolve(&keys)?;
//!
//! // 4. resolve and encode
//! let resolution = doc.resolve(pkgs)?;
//! let composed: Vec<u8> = resolution.encode(EncodeOptions::default())?;
//! # Ok(composed)
//! # }
//! ```
//!
//! See `examples/wac_compose.rs` for a fully runnable version of this
//! pipeline.
//!
//! # Side effects on disk
//!
//! Both [`splice`] and [`compose`] write files as part of their work:
//!
//! - [`splice`] writes one `.wasm` file per sub-component into
//! `splits_dir` (the splitter pass), and may write
//! `splicer_adapter_*.wasm` files alongside them (the adapter
//! generator). Adapter paths are surfaced in
//! [`SpliceOutput::generated_adapters`] and [`SpliceOutput::wac_deps`].
//! - Neither function writes the generated WAC source — that's returned
//! in [`SpliceOutput::wac`] / [`ComposeOutput::wac`] for the caller
//! to write wherever they want.
// ── Top-level entry points ────────────────────────────────────────
pub use ;
/// Re-export so consumers pick up the exact cviz version splicer
/// links against, avoiding version-skew on shared types.
pub use cviz;
// ── Shared types ──────────────────────────────────────────────────
/// Types that appear on the public API surface and may be useful to
/// import directly.
// ── Lower-level building blocks ───────────────────────────────────
/// Direct access to splicer's internal pipeline stages, for callers
/// that need finer control than [`splice`] / [`compose`] offer.
///
/// The function signatures here are not stable in the same way the
/// top-level entry points are — they reflect splicer's internal
/// pipeline shape and may change between releases as the pipeline
/// evolves.