Update, 7 October 2026
The module series settles the part of this that vendor crates need. A module's crate lives at crates/<type>/<vendor> and is named by that path, so crates/device/fastly is the fastly device module, crates/permission-signal/gpp is permission-signal.gpp, and an Edge Cookie module goes under crates/edgecookie/<vendor> (#1043, #1044, #1045, with the rule stated in the design in #1084). The adapters, core, CLI and support crates stay where they are, so moving them under crates/adapters and crates/support is the mechanical move this issue describes and is still open.
Description
The workspace currently keeps its adapters, core library, CLI, integration tests, JavaScript bundle, and OpenRTB crates directly under crates/. Grouping crates by role may make the growing workspace easier to navigate, but this is a mechanical layout change that should preserve package names, Cargo aliases, build outputs, and runtime behavior.
Current evidence
Cargo.toml currently lists ten workspace members, including Fastly, Axum, Cloudflare, and Spin adapters; the earlier issue text listed only three adapters and proposed future module crates that have not been added. The Fastly adapter remains the sole default-members entry so Viceroy can find its binary.
Proposed structure
Agree exact names before moving files. A candidate shape is crates/adapters/{fastly,axum,cloudflare,spin}, crates/core, crates/<type>/<vendor> for module crates, which is the layout the module series uses, and crates/support/{cli,js,openrtb,openrtb-codegen,integration-tests}. Keep all existing Cargo package names unchanged. Avoid creating empty module placeholders solely for the directory layout.
Work involved
Update workspace member paths, path dependencies, .cargo/config.toml aliases, adapter manifests, Fastly/Spin build paths, CI filters, scripts, and documentation links affected by the moves. Coordinate timing with in-flight branches because renames will cause rebase conflicts.
Done when
Related
Proposed originally to support future pluggable module crates.
Update, 7 October 2026
The module series settles the part of this that vendor crates need. A module's crate lives at
crates/<type>/<vendor>and is named by that path, socrates/device/fastlyis thefastlydevice module,crates/permission-signal/gppispermission-signal.gpp, and an Edge Cookie module goes undercrates/edgecookie/<vendor>(#1043, #1044, #1045, with the rule stated in the design in #1084). The adapters, core, CLI and support crates stay where they are, so moving them undercrates/adaptersandcrates/supportis the mechanical move this issue describes and is still open.Description
The workspace currently keeps its adapters, core library, CLI, integration tests, JavaScript bundle, and OpenRTB crates directly under
crates/. Grouping crates by role may make the growing workspace easier to navigate, but this is a mechanical layout change that should preserve package names, Cargo aliases, build outputs, and runtime behavior.Current evidence
Cargo.tomlcurrently lists ten workspace members, including Fastly, Axum, Cloudflare, and Spin adapters; the earlier issue text listed only three adapters and proposed future module crates that have not been added. The Fastly adapter remains the soledefault-membersentry so Viceroy can find its binary.Proposed structure
Agree exact names before moving files. A candidate shape is
crates/adapters/{fastly,axum,cloudflare,spin},crates/core,crates/<type>/<vendor>for module crates, which is the layout the module series uses, andcrates/support/{cli,js,openrtb,openrtb-codegen,integration-tests}. Keep all existing Cargo package names unchanged. Avoid creating empty module placeholders solely for the directory layout.Work involved
Update workspace member paths, path dependencies,
.cargo/config.tomlaliases, adapter manifests, Fastly/Spin build paths, CI filters, scripts, and documentation links affected by the moves. Coordinate timing with in-flight branches because renames will cause rebase conflicts.Done when
wasm32-wasip1, andwasm32-unknown-unknownchecks and the JS build pass with no intended runtime behavior change.Related
Proposed originally to support future pluggable module crates.